Ein Anlass war Conrad’s Beitrag "MVC is dead, it’s time to MOVE on.", in dem er schreibt

"the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it.”

http://cirw.in/blog/time-to-move-on.html (Betonung von mir)

Der andere Anlass war "Best Practices for ASP.NET MVC", sinnigerweise von einem Microsoft-Mitarbeiter:

"Model Recommendations
The model is where the domain-specific objects are defined. These definitions should include business logic (how objects behave and relate), validation logic (what is a valid value for a given object), data logic (how data objects are persisted) and session logic (tracking user state for the application)."

"DO put all business logic in the model.
If you put all business logic in the model, you shield the view and controller from making business decisions concerning data."

http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx

Vergleichbare Aussagen findet man genügend.

Ich tue mich schwer, diese Aussagen zu akzeptieren; oder, um es deutlich zu sagen: Ich halte sie für grundfalsch.

Diese Aussagen sind offensichtlich von der Vorstellung getrieben, dass das MVC-Pattern die gesamte Anwendungsarchitektur bestimmt. Das ist nicht der Fall!

Das MVC-Pattern – gerade in Web-Anwendungen und ganz sicher in ASP.NET MVC – ist ein UI-Pattern. Damit gehört es in den Presentation Layer!

Damit beziehe ich mich auf die handelsübliche, klassische 3-Schichten-Architektur für Web-Anwendungen…

Im Bild folgendermaßen:

Und so ist das Zusammenspiel:

• Das Model kapselt die Daten für die Darstellung. Das kann Validierungsinformationen, etwa als Attribute, oder -logik beinhalten, sofern sie für die Darstellung relevant sind. Außerdem bevorzuge ich value objects (im Gegensatz zu business objects).
• Der Controller nimmt den eingehenden Request entgegen, ruft die entsprechenden Methoden des Business Layers auf, entscheidet über den nächsten Schritt im Page Flow, sammelt (wiederum über den Business Layer) die notwendigen Daten, und reicht diese an die entsprechende View weiter.
  Mit anderen Worten: Der Controller orchestriert den Ablauf, aber er delegiert die eigentliche Arbeit.

Zurück zu den ursprünglichen Zitaten…

• Wenn jemand zu viel Code in seine Controller packt ("you end up stuffing too much code into your controllers"), dann ist das Problem nicht MVC selbst. Es liegt nicht daran, dass Controller “by design” (bzw. aufgrund inhärenter Defizite des Patterns) zur Ansammlung von Code tendieren würden. Es ist viel wahrscheinlicher, dass der Controller Dinge tut, die er nicht tun sollte. (Die Formulierung “you don’t know where else to put it” bekommt damit eine ungewollte Bedeutung.)
• Wenn das Model dem Domänen-Model entspricht ("where the domain-specific objects are defined") und man dort Business-Logik implementiert ("put all business logic in the model") um den Controller davon abzuhalten ("shield the view and controller from making business decisions concerning data"), dann hat man übersehen, dass das Domänen-Model und Business-Logik in den Business-Layer gehören.

Glücklicherweise kann man bessere Aussagen durchaus finden (ich bin also nicht ganz alleine):

"In the MVC world the controller is simply a means of getting a model from the view to your business layer and vice-versa. The aim is to have as little code here as is possible."
http://stackoverflow.com/questions/2128116/asp-net-mvc-data-model-best-practices-for-a-newb

Im Vergleich finden sich solche Ratschläge aber leider viel zu selten.