Theoriefrage zum Thema MVC

[phpBuddy]

Hallo zusammen,

das Thema richtet sich offensichtlich an die etwas erfahreneren Programmierer hier, aber selbstverständlich sind alle Meinungen willkommen.

Vergangenes Wochenende habe ich eine interessante und hitzig geführte Diskussion mitbekommen, bei der es um das Model-View-Controller Entwurfsmuster (aka MVC Pattern) ging. Viele Programmierer verwenden fertige oder eigene MVC Frameworks und da hat wohl so jeder seine eigenen Vorlieben im Umgang mit welcher Code in welche Schicht gehört.

Ein einfaches Beispiel wäre z.B.: Ein Benutzer schaut sich auf einer Webseite, die nach MVC entwickelt wurde, eine Liste mit CDs an. Der User klickt auf einen Link um sich die Titel dieser CD anzeigen zu lassen (domain.tld/cd/titelliste/123). Durch den Klick wird eine neue URL aufgerufen, sprich ein Controller (cd) wird geladen und eine bestimmte Aktion ausgeführt. Der Controller wertet aus welche Aktion gewünscht ist -in unserem Beispiel titelliste- und dieser Aktion wird das Argument 123 übergeben, dass die ID der CD repräsentiert. Die Methode titelliste lädt also das zugehörige Model und übergibt die ID. Das Model besorgt anhand der ID die Daten aus der DB, bereitet sie auf (z.B. legt sie in einem Array ab) und übergibt das Ergebnis an den Controller. Der Controller lädt die Präsentationsschicht (View) und übergibt die Daten, damit die angeforderte Info dem User angezeigt werden kann. Soweit ein kurzes und hoffentlich logisches Beispiel.

Bei besagter Diskussion ging es um das konkrete Beispiel eines Formulars, mit dem sich User registrieren können. Seite anzeigen -> Formular ausfüllen -> Formular abschicken, soweit ist das klar aber dann…!?! Was passiert nun, wenn das Formular abgeschickt wurde? Wo wird die Validierung durchgeführt?
Einige der beteiligten Coder waren der Meinung, dass ein Controller sich wie ein Dispatcher verhalten sollte und delegiert die Aufgaben lediglich. Soll bedeuten, dass der Controller so wenig Code wie möglich enthalten sollte, weshalb die ganze Arbeit an das Model übergeben wird, wo die Daten validiert und gespeichert werden.
Die andere Fraktion (zu der auch ich gehöre) ist allerdings der Meinung, dass das Model ausschließlich für das Speichern/Auslesen von Daten zuständig ist. Sämtliche andere Aufgaben fallen in die Zuständigkeit des Controllers. Im konkreten Beispiel bedeutet das, dass der Controller die Daten validiert und sollten diese okay sein, werden die sauberen Daten an's Model übergeben, damit diese gespeichert werden können.

Wenn man mit verschiedenen Suchbegriffen Google füttert wird einem schnell klar, dass dieses banale "Problem", wo der Code hingehört, gar nicht so banal ist, denn es gibt sehr viele MVC Coder, aber scheinbar gibt es keine einheitliche Regelung in welche Schicht so manch ein Code gehört.

Wie ist das bei euch? Seid ihr auch der Meinung Controller = Dispatcher und die Arbeit erledigt das Model -oder- gehört alles was nicht reine Daten sind in den Controller und hat im Model nix zu suchen?

[MichaG]

Das "Problem" kenne ich als Thin-Controller und Fat-Model vs. Fat-Controller und Thin-Model.

Ich hatte anfangs auch einen aufgeblähten Controller (Validierung etc.) und lediglich das Wegspeichern und Laden im Model.

Mittlerweile bin ich jedoch wieder davon abgekommen. Im Sinne der Modularisierung und Kapselung ist der Fat-Model-Ansatz wesentlich angenehmer - er verhindert Redundanz.

Beispiel: Die Validierung und die Operationen, die nötig sind um einen (neuen) Datensatz zu speichern ist für das Erstellen und Bearbeiten im grundlegenden völlig identisch.
Beim Fat-Model-Ansatz hast du das alles im Model gekapselt - der Controller ruft für das Bearbeiten und Erstellen lediglich eine Methode. Beim Fat-Controller-Ansatz hast du für Aktion Erstellen und Aktion Bearbeiten zur Prüfung zwei mal den selben Quellcode.
Bei Ersterem sind Änderungen im Ablauf wesentlich einfacher zu bewerkstelligen - es muss nur das Model angepasst werden und nicht jeder Controller / jede Aktion, die einen Datensatz speichert.

Sind eben alles nur Richtlinien. Manche greifen auch im View nicht auf präparierte Datenpakete, die vom Model über den Controller zum View gekommen sind, zu sondern operieren im View für lesende Zugriffe direkt auf dem Model.

[marc22]

Ich sehe das ähnlich wie MichaG. Es gibt ja diverse Formular-Klassen (z. B. Zend_Form), bei denen man die Validierung mit in die Definition des Formulars baut. Das hlte ich für die effizienteste Methode. So ist das Formular auch problemlos an anderen Stellen benutzbar.

[phpBuddy]

Mittlerweile bin ich jedoch wieder davon abgekommen. Im Sinne der Modularisierung und Kapselung ist der Fat-Model-Ansatz wesentlich angenehmer - er verhindert Redundanz.

Beispiel: Die Validierung und die Operationen, die nötig sind um einen (neuen) Datensatz zu speichern ist für das Erstellen und Bearbeiten im grundlegenden völlig identisch.
Beim Fat-Model-Ansatz hast du das alles im Model gekapselt - der Controller ruft für das Bearbeiten und Erstellen lediglich eine Methode. Beim Fat-Controller-Ansatz hast du für Aktion Erstellen und Aktion Bearbeiten zur Prüfung zwei mal den selben Quellcode.

Dieses Argument hatten wir auch. Die Kapselung kann man genauso einfach im Controller machen, indem man die Validierung in eine eigene Methode packt und sie aus anderen kleinen Methoden für Erstellen, bzw. Bearbeiten aufruft. So hat man lediglich eine zusätzliche Methode die nichts anderes macht, als die Validierungs-Methode aufzurufen.

Hat man die komplette Validierung im Model, ist es aber nicht mehr so einfach möglich die Datenquelle von z.B. DB auf Flatfile umzustellen. Man müsste das gesamte Model, inklusive Validierung neu schreiben. Widerspricht das nicht dem Prinzip des Models? Die Datenschicht existiert doch als solche, dass man sehr einfach und unabhängig die Datenquelle austauschen kann, ohne große Teile des verarbeitenden Code neu schreiben zu müssen.
Wenn ich die Daten im Controller validiere, aufbereite und in ein Array packe, kann ich dieses Array einfach an das Model übergeben mit der Aufforderung "speicher das mal". Ob das Model das nun in eine Datei speichert, in eine DB schreibt oder sontwas damit anstellt, kann dem Rest der Applikation ja egal sein.

Sind eben alles nur Richtlinien. Manche greifen auch im View nicht auf präparierte Datenpakete, die vom Model über den Controller zum View gekommen sind, zu sondern operieren im View für lesende Zugriffe direkt auf dem Model.

Ja glaube ich mittlerweile auch, dass es vom persönlichen Geschmack abhängt, für welchen Weg man sich entscheidet.

Dieses vermischen, wie es auch marc22 erwähnt, halte ich persönlich für schlecht. Wenn man eh die Validierung im View durchführt oder sich die Präsentationsschicht die Daten direkt vom Model holt, braucht man auch erst gar nicht auf ein MVC System zurückzugreifen, weil man damit ja die Vorteile der Schichttrennung umgeht und sich nichts anderes als Comboscripts bastelt.

Jedenfalls Danke für das bisherige Feedback.

[MichaG]

Das Model setzt sich bei mir selbst nochmal aus einzelnen Schichten zusammen.

Ansprechpartner für die Controller sind bei mir jeweils Services.
Die Services wiederum greifen auf Data-Mapper zu. Die Data-Mapper operieren letztlich auf der Datenquelle.

Der Austausch zwischen diesen Schichten erfolgt mit einem Data-Object, dass z.Bsp. einen Kunden mit entsprechenden Attributen, Gettern und Settern repräsentiert.
Möchte ich statt eines RDMS auf eine NoSQL-Datenbank setzen, tausche ich lediglich den Data-Mapper aus. (Grob gesagt - der Data-Mapper greift selbst nochmal auf ein Object zu, dass die Tabelle im DBMS repräsentiert)
Validierung findet dann im Service statt. Im konkreten Fall heißt das, ich übergebe im Controller dem Service die Post-Daten (Array). Das Array wird im Service durch die Validierung gejagt und anschließend das Data-Object befüllt. Dieses übergebe ich dem Data-Mapper der es dann wegspeichert.