Moin,

Man kann einen Großteil der Geschäftslogik im Model unterbringen, sodass man das Gesamtkunstwerk auch mit unterschiedlichen Controllern oder Views, sogar auf unterschiedlichen Plattformen, gemeinsam nutzen kann.

Ich verstehe Deine Argumentation. Ich glaube aber trotzdem, dass zu viel Geschäftslogik in der Datenbank eher hinderlich ist.
Durch MVC will man ja (u.a.) Abhängigkeiten der Schichten untereinander möglichst vermeiden.
Durch Implementierung der Geschäftslogik in der Datenbank macht man sich aber abhängig von der konkret verwendeten Datenbank, es wird unüberschaubarer, weil man nicht weiss, welcher Teil einer fachlichen Logik in der Datenbank und welcher in den darüber liegenden Software-Schichten unter gebracht ist, und für bestimmte Anwendungsfälle, die nicht direkt in der DB (als stored Procedure o.ä.) implementiert werden können, braucht man dann doch wieder entsprechende Applikationslogik, was widerrum das Risiko erhöht, dass man einzelne Komponenten doppelt schreiben muss (für die Datenbank und die Applikationsschicht).

Trigger, Constraints, Stored Procedures usw. sind IMO eine feine Sache, wenn es um das reine Datenmanagement geht, denn dies ist ohnehin abhängig von der verwendeten Datenbank. Etwas wie "Lösche alle Blog-Artikel von User X, sobald dieser gelöscht wird" kann in einer Oracle-Datenbank und einer MongoDB komplett unterschiedlich aussehen, und ist daher auch direkt in der Datenbank zu implementieren (oder falls das nicht geht, in der Model-Schicht). Es würde für die Abstraktion nichts bringen, so eine Funktion in die höheren Schichten (also z.b. in einen Controller) zu ziehen, da man sie ohnehin ändern muss, sobald man das Model austauschen möchte.
-> An dieser Stelle interessiert den Controller nur, dass er einen User und alle seine Datenobjekte löschen kann - wie das passiert, darum kümmert sich das Model (oder direkt die Datenbank, wenn sie entsprechende Mechanismen bereit stellt).

Wenn es aber um Fachlichkeiten geht, die losgelöst von der Datenhaltung sind (Beispiel: "Berechne den Gesamtpreis aller Produkte im Warenkorb plus Steuer"), ist es IMO sinnvoller, das auch losgelöst davon zu implementieren. Natürlich kann es aus Performance-Gründen notwendig sein, das trotzdem direkt in der DB zu machen, dann muss man das Paradigma an der Stelle verletzen - aber architektonisch sauberer wäre m.E. der andere Weg.

Ist aber natürlich auch nur meine persönliche Meinung.

Viele Grüße,
Jörg