# Model View Controller Architektur



## JavaJ (1. Dez 2010)

Hallo,

ich bin gerade dabei ein kleines Projekt zu erstellen. Dieses soll auf dem MVC Prinzip beruhen.
Jetzt ist meine Frage wie ich die Daten vom Model in die View bekomme. Nach dem Geheimnisprinzip, soll das Model ja komplett unabhängig sein, also müsste ich ja eine Schnittstelle definieren mit get Methoden welche das Model dann einbinden muss. So kann ich ja aber garkeine Datestrukturen übergen, da alle Daten intern im Model gespeichert sind. Wenn ich jetzt beispielsweise etwas auslesen will aus dem Model, dass mehrere Eigenschaften besitzt (Name, Typ, sonstige Attr.) muss ich ja 3x so eine get Methode in der View ausführen.

Ist das MVC Prinzip so gedacht? Oder sollen Klassen im Model auch für die View zugänglich sein, so dass die View sich das ganze Objekt holen kann von dem Model und dann auf dem Objekt selbst Funktionen ausführen kann. Diese Klasse müssten dann halt wieder alle Models die ich austausche einbinden und damit können sie nicht mehr wirklich eine beliebige Datenstruktur erfüllen. 

Oder macht man Klassen die für alle zugänglich sind, wobei bei einer Anfrage das Model eine solche Klasse erstellt und dann mit Daten füllt und an die View zurückgibt. Dann kann sie die Daten intern speichern wie sie möchte und nach außen hin wird die Datenstruktur über die öffentlichen Klassen geregelt.


Ich hoffe jemand versteht mein Problem und kann mir helfen.

Viele Grüße

JavaJ


----------



## XHelp (1. Dez 2010)

Natürlich kannst du auch ganze Objekte holen.
Mit der beliebigen Datenstruktur ist es so eine Sache. Wenn deine Vorüberlegungen richtig sind, dann kommt die Frage erst gar nicht.


----------



## bkalinski (1. Dez 2010)

So habe ich das MVC Pattern erst realisiert. Zwar in C#, aber die Sprache sollte ja egal sein...
Die Modellierung ist nicht ganz ideal sondern nur mal kurz so hingeschmiert.





Ob das Model jetzt wie hier bei mir nur eine Klasse oder ein Interface zu einem Paket ist, ist egal. Ich hatte z.B. im Model nur meine DAOs dran hängen, da meine Anwendung nur Datenbanktabellen schön grafisch aufbereitet hat.

Den Getter des Models soll auch gar nicht aufgerufen werden, sondern die View soll durch das Model "gefüttert" werden. Ansonsten ginge der Sinn des MVC verloren, nämlich die leichte und schnelle Austauschbarkeit der View.


----------



## KSG9|sebastian (2. Dez 2010)

So wie ich es aus dem Model sehe kennt das Model die View bzw. das IView-Interface? Falls ja ist das falsch.

Klassisches MVC sieht so aus:

- Model kennt keine andere Komponenten
- View hängt sich bei dem Model als Listener (Observer) ein um z.B: Änderungen am Model propagiert zu bekommen
- View greift auf Model zu (darf man laut MVC, oft wird es aber so gelöst das die Kommunikation immer View -> Controller -> Model und zurück implementiert wird)
- Controller kennt eine Abstraktion der View (Interaction-Interface)
- View kennt eine Abstraktion des Controllers (Controller-Interface)

View wird oftmals in UI (Toolkit-abhängig) und View (Steuerung der Viewlogik) getrennt.

View und Interactioninterface sollten Toolkit-neutral sein

Letztendlich muss man aber sagen das es zig verschiedene Arten gibt MVC zu implementieren. Besser oder schlechter gibt es da nicht sondern nur passend oder nicht passend für die Anforderung.

Ich verwende mittlerweile auch eher das MVP-Pattern anstatt MVC.

Für die Unterschiede der verschiedenen Patterns würde ich dir empfehlen die Artikel von Karsten Lentsch (Autor JGoodies) zu lesen.

Google "jgoodies articles"


----------



## bkalinski (2. Dez 2010)

Um mal meinem Rechtfertigungsdrang nachzukommen:

In C# gibt es das Observable nicht. Deswegen hab ich es so implementiert, was meiner Meinung nach den Vorteil hat die View besser austauschen zu können. Die neue View muss quasi nur IView implementieren und die Schnittstelle benutzen die der Controller anbietet. Mir war bei projektbeginn schon klar das die geplante View nicht lange so bestehen wird.

Ich denke das ist der wichtigste Gedanke den man sich bei MVC machen sollte: Wieso entwickle ich nach MVC(oder -MVClike *g*) Und was soll mir das MVC Pattern bringen? Nach diesen Überlegungen kann man das Pattern dann immer noch variieren.


----------



## KSG9|sebastian (2. Dez 2010)

View und Controller ist ja auch in Ordnung. Wichtig ist dass das Model weder den Controler noch das Model kennt und auch nicht deren Abstraktionen (meinetwegen IView und IController).

Gerade aus deinen Überlegungen heraus präferiere ich das MVP-Paradigma...


----------



## ThreadPool (2. Dez 2010)

KSG9|sebastian hat gesagt.:


> Gerade aus deinen Überlegungen heraus präferiere ich das MVP-Paradigma...



Wenn man sich aber mal die Originaltexte ansieht wird man schnell merken dass das MVC so wie es mal beschrieben wurde heute so nicht mehr existiert. Deswegen reduziere ich persönlich jede Form von MVC auf die zwei Errungenschaften Trennung von View und Domänenmodell plus Synchronisatin über das Beobachterprinzip. Das Problem ist nicht die Idee des MVC sondern die Rolle der Entitäten dabei. 

Jedenfalls ist das MVP dem MVC sehr ähnlich geht jedoch von anderen Grundgegebenheiten aus, d.h. die beteiligten Entitäten haben andere Rollen die eben besserin die heutige Zeit passen. Des Weiteren wenn man sich das Original-Paper von 1996 zum MVP mal reinzieht wird man schnell merken das da z.B. ein komplettes Messagingsystem zugrunde gelegt wird etc. pp., das wird heute kaum erwähnt. Und welches MVP hättest du gerne, das mit einer komplett passiven View oder eher Supervising Controller-Stil oder das original?

Wichtig ist einfach das man klare Schnittstellen definiert, das man sich Gedanken darüber macht wie sich etwas verändert und wo man überhaupt Veränderung möchte und wie man dafür sorgt das sich das leicht erweitern lässt an diesen Stellen. Dann zählt weiterhin das man nicht versucht das Domänenmodell mit der GUI zu mischen und ob die Elemente der Zwischenschicht dann Presenter- oder Controller oder weiß der Geier heißen ist doch egal. Und natürlich hilft einem beim Implementieren von derart komplexen Systemen dann Wissen über Messagingsysteme - Interkomponentenkommunikation, Plugings, komponentenbasierte Architektur, Design Patterns, API-Design etc.

EDIT: Und das was ich eigentlich sagen wollte war, viele verwenden schon eine Art MVP (z.B. Richtung Def. von Fowler) wenn sie von MVC reden, weil das heute eher eine "natürliche" Art des Umgangs mit z.B. Frameworks wie SWING mit sich bringt.


----------

