Im Zend Framework gibt es keine Basisklassen für Models, also etwa eine Klasse Zend_Model. Man ist der Auffassung, dass Models die Applikationslogik enthalten und daher grundsätzlich applikationsspezifisch sind und demnach nicht Bestandteil eines Framewoks, das ja verallgemeinerungsfähige Prinzipien implementiert, sein können.

Bill Karvin begründet dies in seinem Artikel ActiveRecord does not suck.

Wikipedia definiert ein Model wie folgt:

Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“. …

Bei Webanwendungen kann der Browser nicht nach dem Observer-Muster unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt im HTTP-Protokoll eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es dann nur einen Mehraufwand bedeuten würde, kommt es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.

Nach einem Artikel von Padraic Brady hat ein Model mindestens zwei Aufgaben:

• den Status zwischen zwei Requests zu sichern und
• die gesamte Geschäftslogik zu impelmentieren, die einen solchen Status erzeugt und wiederspiegelt

Das Model repräsentiert demnach die Daten, den Zustand und die Geschäftslogik des Systems. Dies ist das sogenannte “Skinny Controller – Fat Model – Prinzip”.

Üblicherweise wird die Applikationslogik im Controller untergebracht.

Most people simply assumed that MVC worked as follows: requests go to Controllers, Controllers get data from Model, Controller gives Model data to View, Controller renders View. In other words: Controller, Controller, Controller, Controller.

Brady formuliert dazu seinen Meinung recht drastisch:

Since Models are so lame to developers, they invented a new concept. Fat Stupid Ugly Controllers (FSUC). I put the SUC in FSUC on purpose. It seemed funny at 10pm after a few drinks. And less offensive than FUC. These were invented since Models were strange, alien, and possible terrorist entities nobody really trusted with anything other than data access methods.

In my mind, the best Controller is a Controller which doesn’t need to exist

Neben der daraus resultierender Unübersichtlichkeit im Code führt Brady ein weiters wichtiges Argument für Fat Models ein:

The nature of Controllers is such that they are tightly coupled to the underlying framework. You can only make a Controller execute by initialising the entire framework’s MVC stack (potentially dozens of other class dependencies!).

Dies ist dann auch ein starkes Argument gegen allzu viel Model-Basislogik im Framework, ähnlich wie es Bill Karvin begründet.

Brady schlussfolgert:

Models are just a collection of loosely coupled classes. You can instantiate and call them from anywhere – other Models, Controllers and even Views! A Controller, on the other hand, is a tightly integrated cog in the machinery of a whole process. You can’t reuse a Controller without also dragging in the entire process of setting up request objects, dispatching, applying action helpers, initiating the View, and handling returning response objects.

Im Tutorial für das AGAVI-Framework wird das Model wie folgt definiert:

Models are classes that contain your application logic. They access databases, send e-mails, render images, converse with captcha libraries and facilitate the processing of any other data that an application needs. Models are completely disconnected from the user interface of your applications, and Agavi never interacts with them directly.

Actions manipulate your Models using outside data to perform changes to your application state. Views question the Models for relevant data and display it.

When you remove the user interface layer (Actions and Views) all that remains is Models — your application expressed as an API. When your application is available as an API, you can write automated tests to make sure it doesn’t break throughout its development.

Schlussfolgerungen

• Models sind keine einfachen Datenspeicherobjekte, sondern implementieren Applikationslogik.
• Models müssen die darunterliegende Datenspeicherung verbergen. Die Model-Schnittstelle darf also weder Datenbankcode noch Tabellenspalten oder ähnliches enthalten
• Aufgabe der Models ist es
  • Daten zu validieren anhand von Geschäftskriterien,
  • die Daten in die zu speichernde Form umzuwandeln (Normalisierung) und
  • andersherum, die Speicherrepräsentation der Daten in ihre Darstellungsform z.B. durch Lokalisierung zu wandeln

Hier eine zusammenfassende Übersicht über relevante Artikel:

• ActiveRecord sucks, but Kore Nordmann is wrong
• Bill Karwin: ActiveRecord does not suck
• Padraic Brady: The M in MVC: Why Models are Misunderstood and Unappreciated
• Dave Marshall: Fat Models and the Data Access Layer
• Matthew Weier O’Phinney: Model Infrastructure
• Matthew Weier O’Phinney: Using Zend_Form in Your Models
• Matthew Weier O’Phinney: Applying ACLs to Models
• Implementierung von Matthew Weier O’Phinney: PasteBin-Anwendung
• Rob Allen: On models in a Zend Framework application
• Jani Hartikainen: Decoupling models from the database: Data Access Object pattern in PHP
• Ralf Eggert: Zend_Model – Stand der Dinge
• Ralf Eggert: Das M im MVC-Entwurfsmuster
• Jurriën Stutterheim: Zend_Model Component Proposal
• Das AGAVI MVC Framework
• Zend Framework Db Table ORM
• Maarten Balliauw: PHPLinq

Der Beitrag wurde am Sonntag, den 11. Januar 2009 um 15:06 Uhr veröffentlicht und wurde unter Zend Framework abgelegt. Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Kommentare und Pings sind derzeit nicht erlaubt.