Wo ziehen Sie in MVC die Grenze zwischen einem Controller und einem Modell? [closed]

Ich habe geschriebenen Code gesehen, bei dem fast der gesamte nicht routenbezogene Code an ein Modell übergeben wird. Ich habe auch Code gesehen, bei dem die gesamte Datenbankpersistenz von einem Modell gehandhabt wird, die Nicht-DB-Verarbeitung jedoch vom Controller gehandhabt wird.

Welches ist der bessere Ansatz?

Die Grenze zwischen Controller und Model ist eigentlich ganz klar.

Model ist das Herzstück Ihrer Bewerbung. Es enthält die Geschäfts-/Domänenlogik, die erforderlich ist, um das Problem zu lösen, für das Ihre Anwendung geschrieben wurde. Das Modell ist normalerweise in mehrere andere Schichten geschichtet, z. B. Persistenz, Dienste, Domäne usw. Es ist ein weit verbreitetes Missverständnis, dass das Modell nur die Datenbank ist, ebenso wie es ein weit verbreitetes Missverständnis ist, dass die Datenbank ein ActiveRecord sein sollte.

Der Controller (und die Ansicht) sind Teil der Präsentationsschicht. Die alleinige Verantwortung eines Controllers besteht darin, an Ihre Anwendung gerichtete Benutzereingaben zu empfangen und zu verarbeiten und diese an die entsprechenden Teile im Modell zu delegieren. Nichts mehr. Es sollte keinen komplexen Anwendungsfluss oder Code Ihrer Problemdomäne verarbeiten. Sie möchten, dass die Controller dünn und die Modelle fett mit Logik sind. Das Modell sollte weder C noch V kennen, und Sie sollten in der Lage sein, V und C gegen eine andere Präsentationsebene auszutauschen, ohne Ihr M berühren zu müssen.

Sehen MVC-Auszug in Patterns of Enterprise Application Architecture