Das Zend Framework hat es richtig gemacht: ein MVC-Framework, das kein M(odel) zur Verfügung stellt.
Wie kann ein MVC-Framework ohne ein M(odel) vollständig sein?
Nun, weil es nicht nur ein mögliches Model gibt. Und vielleicht auch, weil die meisten Entwickler, die aus der klassischen und ebenso gesetzten LAMP-Welt kommen, glauben, ein Model sei in erster Linie die Abbildung bzw. Umwandlung einer (statischen) Datenbankstruktur in eine objektorienterte Struktur.
Ein Model ist in erster Linie, nun ja, eben ein Modell. Und ein Modell ist immer eine vereinfachte Darstellung eines komplexen Systems oder Zusammenhangs. Das Modell eines Flugzeugs kann nicht fliegen aber man kann es im Windkanal testen und man gewinnt einen Eindruck des späteren Aussehens. Ein Modell bildet niemals das gesamte ferige Produkt ab, sondern vereinfacht und abstrahiert dessen Konzepte.
Merke: Ein Modell, dass nicht abstrahiert, ist keines.
Ein Modell ist also eine Abstraktion der realen Welt (bildet diese aber niemals 1:1 ab!), mit Objekten, die sich einen Teufel darum scheren, wie sie in statischen Strukturen abgebildet werden. Sie leben und sie tun etwas. Manche von ihnen sterben und andere werden geboren.
Allein daraus lässt sich ableiten, dass es mindestens zwei Modelle geben muss: eines für “lebendige” Objekte und eines für die statische Abbildung von Objekten, quasi für “veraltete Daten”. Und es kann noch beliebig weitere Modelle geben, je nachdem, welche Abstraktionen benötigt werden.
Aus diesen gewagten Behauptungen erkennt man, welch weise Entscheidung Zend getroffen hat (ob gewollt oder nicht).
Welchen Sinn machen dann MVC-Frameworks überhaupt?
MVC sollte vor allem als ein logisches Pattern gesehen werden. Wie man dann V, C und M implementiert, das ist (wie so oft) für den jeweiligen Anwendungsfall speziell zu entscheiden. Viel wesentlicher ist nämlich, dass man überhaupt die Dinge voneinander trennt, also statische von dynamischen Inhalten, das Lesen vom Schreiben von Daten und Objekten und lebendige von toten Objekten (also deren statischem Abbild).
Da Views und Controller meist einen ähnlichen technischen Background und Lösung von vielen wiederkehrenden Anforderungen sind (z.B. Routing), macht ein Framework sicherlich einen Sinn.
Wobei hier auch anzumerken ist, dass oftmal nur die Controller relativ simpel bleiben (sollten), Views können eine hohe Komplexität erreichen. Aber das sind Themen für andere Artikel …
Letztendlich ist das Zend MVC Framework wie jedes andere Framework nur ein Baukasten mit verschiedenen Werkzeugen, dass die Abarbeitung der mechanischen und immer wiederkehrenden Aufgaben und Arbeitschritte erleichtert. Aber keinesfalls die eigentliche Geschäftslogik baut, um die es letztendlich in einer eigenständigen Applikation geht.
Wäre die nämlich auch zu vereinheitlichen und automatisierbar, warum würde man dann etwas bauen, was es schon gibt?