Hello,

In erster Linie aus historischen Gründen. Damals galten andere Paradigmen der Anwendungsentwicklung.

In heutigen MVC-Webanwendungen – zumindest bei denjenigen, von denen hier die Rede ist – wird solche Logik in aller Regel im Anwendungscode implementiert. Von der Datenbank wird durch objekt-relationale Mapper abstrahiert.

Man legt die Geschäftsregeln und das Datenbankmodell nicht deshalb ins Model (das ist selten identisch mit den Datenbankmodell), weil das "historisch gewachsen" ist, sondern weil man versucht das Model als Kern zu kapseln. Im Prinzip müssen sich in der Praxis daher alle anderen Module um das Model gruppieren und nicht etwa um den Controller.

Die Kapselung hat zur Folge, dass eine hierarchische Struktur bei der Entwicklung und späteren Benutzung eingehalten werden kann. Das Model ist sozusagen das "Heiligtum" des Unternehmens. Dort hinein haben nur Wenige den vollen Eingriff. Zugriffe darauf müssen über streng definierte und kontrollierte Schnittstellen stattfinden.

Wenn in einer Bank eine neue Schaltersoftware eingeführt wird, bleibt das Heiligtum (Model, Datenbank) möglichst unangetastet. Das spielt sich dann im View und im Controller ab. Ist natürlich jetzt arg vereinfacht, aber so kann man besser verstehen, WARUM heute die Geschäftsregeln wieder möglichst alle ins Model verlagert werden.

Wenn sogar die Wikipedia das so schreibt, muss es doch stimmen *höhöhö* ;-D

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg