MVC Design Pattern - Wie denn nun?!

[Gurki]

Hallo,

ich hatte gerade mit einem Arbeitskollegen eine kleine Diskussion wegen des MVC Design Patterns. Irgendwann muss man damit ja mal anfangen, also tat ich dies nun mal endlich. In der Schule wurde mir folgendes beigebracht:

View = Gui -> Das was der Nutzer sieht - Verständlich

Model = Datenhaltung -> Hält die Daten per Getter- / Setter-Methoden - Ansich verständlich

Controller = Steuerung -> Hier wird die Logik abgehandelt

Und genau da hatte ich meine Diskussion: Wie läuft denn das nun? Ist der Controller "dumm" und gibt die Daten immer nur weiter zwischen View und Model oder wird hier auch richtige Logik abgehandelt? Mein Arbeitskollege meinte, dass im Model zwar Datenhaltung stattfindet, aber hier die eigentliche Logik auch abgehandelt wird.

Nehmen wir mal ein Beispiel: Es sollen Daten aus einer Datenbank gezogen werden und sortiert in eine ArrayList geschrieben werden. Wo findet dieses Prozedere nun statt? Im Model oder im Controller?

Wenn man es jetzt wie der Lehrer im Controller machen würde, dann wäre das ja ein einziges hin und her und zwar:

Von der Datenbank in den Controller und vom Controller in das Model. Und von dort wieder zum Controller und zur View... Eigentlich Quatsch.

Wäre es nicht Sinnvoller, wie mein Kollege sagte, die Logik dann im Model (oder in einer extra Klasse, die nur das Model kennt ?) machen lassen und die Daten dann dem Controller weiter zu geben und der gibt diese dann der View weiter?

Also ansich habe ich das Konzept in der Theorie verstanden, aber wie man es nun praktisch anwendet verstehe ich noch nicht so recht.

[lilith2k3]

Galileo Computing :: Praxisbuch Objektorientierung – 8.2 Die Präsentationsschicht: Model, View, Controller (MVC)

[pr0gg3r]

Und genau da hatte ich meine Diskussion: Wie läuft denn das nun? Ist der Controller "dumm" und gibt die Daten immer nur weiter zwischen View und Model oder wird hier auch richtige Logik abgehandelt? Mein Arbeitskollege meinte, dass im Model zwar Datenhaltung stattfindet, aber hier die eigentliche Logik auch abgehandelt wird.

Der Controller ist nicht dumm! Der Controller legt fest, welche Daten geladen bzw. welches Model aufgerufen wird und welche View aufgerufen wird. Der Controller kann Logik enthalten, zB "Nehme Formulardaten von Benutzer, gebe ihn an Model, wenn Model damit nichts anfangen kann (nicht die erwarteten Daten) dann Fehlermeldung-View aufrufen". Oder noch simpler: "Wenn nicht eingeloggt, dann Loginformular-View aufrufen.

Das Model kann genauso Logik enthalten, aber eben nur Logik der Daten betreffend. Beispiel: Du gibst eine Anfrage an das Model: "Lösche Datensatz mit ID x", dann kann im Model genauso (logisch) abgefragt werden, ob es den Datensatz überhaupt gibt. Solche allgemeinen Dinge hast du dann in der Mode-Klasse (von der du dene Models ableitest, haben also alle Kinder-Modelle). Verifizierungen usw. kannst du dann in die Kindklasse expliziet programmieren (zB dass ein Passwort-Datensatz bestimmte Richtlinien hat). Aber alle anderen logischen Dinge, die keine Daten(sätze) betreffen, gehören nicht ins Model!

Nehmen wir mal ein Beispiel: Es sollen Daten aus einer Datenbank gezogen werden und sortiert in eine ArrayList geschrieben werden. Wo findet dieses Prozedere nun statt? Im Model oder im Controller?

Wenn man es jetzt wie der Lehrer im Controller machen würde, dann wäre das ja ein einziges hin und her und zwar:

Von der Datenbank in den Controller und vom Controller in das Model. Und von dort wieder zum Controller und zur View... Eigentlich Quatsch.

Das ist kein Quatsch sondern eine Möglichkeit, Daten von Logik und Ansichten zu trennen. Deshalb gibt es das ja und dann muss es eben rumgeschubst werden. Bei kleineren Projekten fragt man sich, ob das wirklich sein muss, bei großen Projekten erhält man so schnell eine schöne, klare und übersichtliche Struktur.

Es gibt immer zuerst(!) ein Controller, nicht das Model. Der Controller fragt Daten an und ruft ggf die View auf.

Bei deinem Beispiel:

1. Controller "lade Datensatz und zeige Liste an" wird aufgerufen

2. Dieser sagt zum Model: "Hole mir die Daten X aus Datenbank Y" (liefert Array zurück)

3. Der Controller nimmt die zurückgegeben Daten entgegen und gibt sie an die View weiter ("Liebe View, hier hast du die Daten, mach was schönes damit")

4. Der Controller zeigt die entsprechende View an (die den übergeben Array formatiert ausgibt)

Wäre es nicht Sinnvoller, wie mein Kollege sagte, die Logik dann im Model (oder in einer extra Klasse, die nur das Model kennt ?) machen lassen und die Daten dann dem Controller weiter zu geben und der gibt diese dann der View weiter?

Dann könntest du auch den Controller übergehen und die Daten direkt aus dem Model an die View geben. Dann hast du aber kein MVC sondern sondern nur vom restlichen Script getrennte Ansicht.

Also ansich habe ich das Konzept in der Theorie verstanden, aber wie man es nun praktisch anwendet verstehe ich noch nicht so recht.

Ich denke, du brauchst noch ein wenig, bis du das Konzept wirklich verstanden hast. Ich habe mir auch sehr lange darüber Gedanken gemacht, habe mir alle bekannten MVC-Frameworks für PHP angeschaut (Zend-Framework, Codeigniter, CakePHP, Prado, ...). Jedes hat andere Ansätze. Man kann hat natürlich auch einen Interpretationsspielraum, wie man MVC sehen kann/könnte. Ich verstehe es ehrlich gesagte erst richtig gut, seitdem ich selber nach einigen Versuchen und vielen vielen Stunden rumprogrammieren/rumprobieren eine vernünftige Architektur auf die Beine gestellt habe.

Also: Versuch dein eigenes MVC zu programmieren, da treten viele Fragen auf, die du dann mit Blick auf bekannte MVC-Frameworks und etwas Nachdenken sicherlich lösen kannst. Und dann hast du auch relativ schnell verstanden, worum es wirklich geht. Und dass das Model sehr wohl Logik hat (sonst bräuchte man kein Model sondern nur eine Datenbank).

[lilith2k3]

Naja, ganz so einfach und eindeutig wie pr0gg3r das hier formuliert ist es auch nicht. Vorallem, weil es MVC in Reinform so in natura kaum (noch) anzutreffen gibt. Aus dem oben von mir verlinkten Artikel sollten die Begrifflichkeiten klar geworden sein, aber auch die Offenheit. Ursprünglich ging es eben um ein Problem der Trennung von Eingabemechanismen und Darstellungsformen für die zu bearbeiteten Daten. Die Form von MVC wird heute nicht mehr verwendet. Überlebt hat stattdessen die Idee der "Separation of concerns", wo man die Darstellung von den Daten getrennt hat. Und irgendwo dazwischen agieren die Controller. Diese Variante gibt es in zig Spielarten: die einen eher klassisch angehaucht, die ein reiches Objektmodell vorsehen oder eher andere, wo das Datenmodell lediglich Datenhalde/"Durchreiche" für die Daten ist. Und je nach Glaubensrichtung nennt sich das ganze "MVC". Und schwierig wird es bei Frameworks wie Backbone.js, die man bestenfalls MV* nennen sollte (also »irgendwie MV ohne C oder so«).

Das Model kann genauso Logik enthalten, aber eben nur Logik der Daten betreffend. Beispiel: Du gibst eine Anfrage an das Model: "Lösche Datensatz mit ID x", dann kann im Model genauso (logisch) abgefragt werden, ob es den Datensatz überhaupt gibt.

Das finde ich schon recht schwierig in einem reinen MVC-Model unterzubringen.

Sind die Datensätze das Modell der einzelnen Daten und das Repository/der DAL ein (Meta-)Modell der Datensätze? Und wer fragt ab, ob es diesen Datensatz gibt? "Fragt" das Repository? oder eher ein "Service-Controller"?

Von der Datenbank in den Controller und vom Controller in das Model. Und von dort wieder zum Controller und zur View... Eigentlich Quatsch.

Hm. Die wirklichkeit ist in der Regel noch komplizierter:

In aller Regel hat man einen Persistenzlayer wie (N)Hibernate(.NET/Java), Java JPA, SpringData (Java), Entity-Framework(.NET), ActiveRecord(Ruby) usw. usf. Das Teil ist dafür verantwortlich, Daten aus der Datenbank zu quetschen und irgendwie in Dein Objektmodell zu klöppeln (Stichwort »ORM«). Von anderen (Service-)Controllern werden Daten vom Persistenzlayer angefordert; und je nachdem werden die Daten noch aufbereitet und an einen höheren Layer weitergereicht, der die Daten für die Präsentation aufbereitet oder man reicht sie ohne Aufbereitung weiter.

bei großen Projekten erhält man so schnell eine schöne, klare und übersichtliche Struktur.

Besser ausgedrückt: In eine klare und übersichtliche Struktur kann man auch (irgendwas mit) MVC (-aussehendes) einbauen.

Dann könntest du auch den Controller übergehen und die Daten direkt aus dem Model an die View geben.

Was nach der reinen Lehre auch geschieht. Die View ist Observer des Models und erhält quasi im Abo seine Updates.

Dann könntest du auch den Controller übergehen und die Daten direkt aus dem Model an die View geben.

Naja, doch. Eben das "alte" Smalltalk-MVC...

Ich denke, du brauchst noch ein wenig, bis du das Konzept wirklich verstanden hast.

Sagen wir besser: Bis Du den Markt an MV*-Ansätzen überblickt hast.

Sinnvollerweise sollte man in meinen Augen heute nicht mehr von MVC reden, sondern eben "Separaion of concerns", was ja die Grundidee von MVC war, aber was heute viel weiter und umfassender ist als reines MVC.

[Gurki]

Faszinierend! Ich danke Euch für Eure Beiträge - auch wenn ich nur die Hälfte verstanden habe Ist das jetzt schlimm? Mache im Sommer einen Abschluss... Aber die ganzen Begrifflichkeiten sagen mir irgendwie noch nicht wirklich viel. Glaube ich muss noch viel lernen...

[lilith2k3]

Ich danke Euch für Eure Beiträge

Bitte. gerngeschehen

Ist das jetzt schlimm?

Nö.

Glaube ich muss noch viel lernen

Geht am Schnellsten, wenn Du die Sachen erfragst, die Dir unklar sind

[SaintsRow]

Generell ist es vorteilhaft, sich ein wenig mit Design Patterns auszukennen.

In meinem letzten Bewerbungsgespräch wurde ich konkret nach dem MVC Pattern gefragt. Ich konnte gut antworten, weil ich mein Abschlussprojekt danach aufgebaut hatte.