[Magnus_A]

Finns olika filosofier.
FatControllerSkinnyModel där man lägger logiken i controllern, och
SkinnyControllerFatModel där man flyttar ut logiken till modelen, som du föreslår.

Själv föredrar jag att lägga logiken i en Helper, så blir både Controller och Model magra.

Nånstans måste ju logiken ligga.

Apropå filosofier är de nog ingen slump att alla demos för MVC frameworks handlar om bloggar där man bara skyfflar data rakt ut på sidan, utan logik. Det är när logiken kommer in som det blir krångligt och man måste börja kompromissa.
Typ att man har liknande logik i ett par tre olika controllers/models, ska man då göra specifika funktioner i var och en, eller en generell men lite krångligare i en helper som alla kan anropa? Inget enkelt svar. När man börjar ändra visar det sig om man tänkt rätt eller inte.

[dAEk]

Vad skulle vara bra med att lägga affärslogiken sina controllers? Jag har svårt att se eventuella fördelar.

Några nackdelar kan jag komma på:

1. Det blir tight coupling mellan modellen och controllern.
2. Det strider mot SoC (Separation of Concerns) och SRP (Single Responsibility Principle).
3. Koden tenderar att bli rörig och svårhanterlig - speciellt om det är flera utvecklare i projektet. Metoderna blir långa och krångliga. De flesta av oss är inte så disciplinerade att vi klarar av att hålla blandningen mellan model- och controller-kod på en lagom (vad det nu innebär) nivå.
4. Unit-testing blir svårare.