Model View Controller Architektur

JavaJ

Mitglied
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

Top Contributor
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

Mitglied
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.
klassendiagramm8f1k.png

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

Top Contributor
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

Mitglied
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

Top Contributor
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

Bekanntes Mitglied
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. :)
 
Zuletzt bearbeitet:
Ähnliche Java Themen
  Titel Forum Antworten Datum
H Model-View-Controller Fail? Allgemeine Java-Themen 31
M Model View Controller Entwurfsmuster! Allgemeine Java-Themen 11
M Java model class ? Allgemeine Java-Themen 9
J Variablen Array ertellen bei model.put Allgemeine Java-Themen 13
Slevin MVC Model Allgemeine Java-Themen 9
P MVC - Frage zu Model Allgemeine Java-Themen 4
S JTable: Model durch ein anderes ersetzen Allgemeine Java-Themen 2
P Model + ModelInterfaces Allgemeine Java-Themen 10
G Transaction Script, Table- Domain Model Allgemeine Java-Themen 2
B Daten an Tabel Model übergeben Allgemeine Java-Themen 8
G Domain Driven Design Model Allgemeine Java-Themen 14
G Mediator-Model Allgemeine Java-Themen 7
M Model für Dateimanager Allgemeine Java-Themen 3
M In der GUI / im Model auf Webrequest warten? Allgemeine Java-Themen 4
borobudur MVC Model Generator Allgemeine Java-Themen 2
S Model richtig aktualisieren Allgemeine Java-Themen 7
E model.getchild Allgemeine Java-Themen 8
Z JTextField mit Model kommunizieren Allgemeine Java-Themen 6
B View communication eclipse Allgemeine Java-Themen 17
Crashbreaker RCP-View Image öffnen und darstellen Allgemeine Java-Themen 7
B A newer version of Java is needed to view the application. Allgemeine Java-Themen 17
K Immutable View auf StringBuffer? Allgemeine Java-Themen 13
T Pattern: Passive View Allgemeine Java-Themen 2
B MVC: controller in unabhängigen thread von der view starten (gui friert ein) Allgemeine Java-Themen 5
G Trennung View und Control Allgemeine Java-Themen 3
M Frage zur View Klasse des MVC Prinzip Allgemeine Java-Themen 3
O Service oder Controller Allgemeine Java-Themen 6
M Best Practice MVC- Was gehört in den Controller? Allgemeine Java-Themen 1
K Java FX Zu startenden FXML-Controller per Parameter wählen Allgemeine Java-Themen 2
X Controller pro Frame? Allgemeine Java-Themen 8
K GUI-Entwicklung - Dispose, enabling und mehrere Controller Allgemeine Java-Themen 1
D GUI-Controller Konzept Allgemeine Java-Themen 6
O Formularinhalte der jsp in Controller nicht greifbar Allgemeine Java-Themen 2
T MVC - Controller verbessern Allgemeine Java-Themen 9
Y Exception Handling - Controller-Businesslogik-Persitenz Allgemeine Java-Themen 7
G Problem mit MVC-Pattern (Controller als anonyme Unterklasse) Allgemeine Java-Themen 2
N XInput API (DLL für XBox 360 Controller) mit Java benutzen? Allgemeine Java-Themen 3
K MVC - Kommunikation Controller <> Gui Allgemeine Java-Themen 5
D Controller für GUI (MVC) Allgemeine Java-Themen 6

Ähnliche Java Themen

Neue Themen


Oben