MVC vs MVA

[Gast2]

Hallo zusammen,

ich versuche gerade den genauen Unterschied von MVA und MVC herauszufinden, sowie die Vor- Nachteile beider Architekturmuster. Kennt jemand vielleicht eine gute Seite oder kann etwas dazu erklären?
Ich weiß nur Swing arbeitet mit MVC und SWT/JFace mit MVA, aber der genaue Unteschied ist mir noch nicht ganz klar.

 

[ThreadPool]

IMHO liegt der Unterschied nur in der Art der Kommunikation, die Schichten (Darstellung, Verarbeitung, Domänenmodell (bzw. Application Model + Domain Model) ) sind strikt voneinander getrennt. Jegliche Art von Kommunikation läuft über die Verarbeitungschicht die eine Art Mediator darstellt. Dafür gibts dann natürlich auch wieder von x-y verschiedene Interpretationen und Implementierungen eine z.B. wäre das MVP (Dolphin-Stil) mit PassiveView (Fowler). Das lässt sich wie folgt beschreiben View delegiert Input an den Presenter (oder Adapter), dieser veranlasst die Änderungen in der View, ändert den Zustand der View und ändert das Model entsprechend. Das Model bemerkt seine Änderung, schiebt ein Event an den Presenter (o. Adapter) der fragt das Model nach den passenden Daten und schickt diese Weiter an die View.

Der "Vorteil" einer strikten Trennung der Schichten ist eine bessere Testbarkeit da du z.B. die Mittelschicht testen kannst und nur sicher stellen musst das die Widgets der View richtig befüllt werden. Des Weiteren ist es natürlich immer praktisch wenn es vernünftige Schnittstellen gibt, da man dann noch viel einfacher z.B. Views austauschen kann, ja sogar ganze Presenter (o. Adapter).

Das bringt natürlich auch alles gleich mal einiges mehr an Aufwand mit sich, es ist halt die Frage ob man das benötigt oder eben nicht.

 

[Gast2]

die Schichten (Darstellung, Verarbeitung, Domänenmodell (bzw. Application Model + Domain Model) ) sind strikt voneinander getrennt.

Ist auch bei MVC so.

Schichtentrennung sind bei beiden Muster gegegeben.
Genauso kann bei MVC der Controller die View und Model verändern.

Bei MVA versteh ich das der Adapter die View kennt und auf Änderungen reagiert und View aktualisiert oder sogar der Apdapert sagt wie die View die Daten darstellen z.b. TableViewer und LabelProvider.

Bei MVC registriert sich eher die View als Listener an das Model.

Aber wie gesagt genaue Vor- und Nachteile kann ich nicht unbedingt erkennen. Ein cooles einleuchtendes Beispiel wäre toll...

 

[maki]

Swing setzt u.a. auf den JavaBeans Standard, da sind Getter/Setter, PropertyChangeListener etc. standartisiert, passen aber manchmal nicht wirklich ins Konzept der Domäne

SWT/JFace ist da flexibler, du musst deine Domänenklasse nicht nach dem JavaBeans Standard ausrichten (und büsst u.U. keine Objektorientierung ein, etc.), alles was funktionieren muss - also GUI Ansprüchen im Sinne der Schnittstelle genügen muss - ist der Adapter, der am besten aus einer AdapterFactory kommt

 

[ThreadPool]

Ist auch bei MVC so.

Schichtentrennung sind bei beiden Muster gegegeben.
Genauso kann bei MVC der Controller die View und Model verändern.

Naja nicht ganz, wenn die View das Model kennt hat man dann eine schichtenübergreifende Kommunikation (was um himmelswillen nichts Schlimmes sein muss). Und du hast notfalls zwei Stellen an denen du die Schnittstelle des Models anpassen musst.

Wenn du jetzt argumentierst das man den Controller ja in die Mitte packen kann hast du erkannt das die heutige Interpretation des MVC mehr eine Art von "Architekturfamilie" darstellt in die so ziemlich alles reinpasst wenn man nur ansatzweise an die Trennung von Domäne, Darstellung und Verarbeitung denkt, nur sind die Verantwortlichkeiten teilweise anders, die Kommunkationswege unterscheiden sich und die Namen sind natürlich fescher. Mit einem coolen Beispiel kann ich leider nicht dienen.

 

[maki]

Naja nicht ganz, wenn die View das Model kennt hat man dann eine schichtenübergreifende Kommunikation (was um himmelswillen nichts Schlimmes sein muss).

Nun ja, das Modell könnte auch nur ein PresentationModel sein
Oder ein POJO das als EJB3 EntityBean fungiert, da wäre auch nix mit schichtenübergeifender Kommunikation.

 

[Gast2]

Swing setzt u.a. auf den JavaBeans Standard, da sind Getter/Setter, PropertyChangeListener etc. standartisiert, passen aber manchmal nicht wirklich ins Konzept der Domäne

SWT/JFace ist da flexibler, du musst deine Domänenklasse nicht nach dem JavaBeans Standard ausrichten (und büsst u.U. keine Objektorientierung ein, etc.), alles was funktionieren muss - also GUI Ansprüchen im Sinne der Schnittstelle genügen muss - ist der Adapter, der am besten aus einer AdapterFactory kommt

PropertyChangeListener und der ProprtyChangeSupport ist ein richtiger krauss ^^...

Ok die Flexibilität kann ich nachvollziehen.
Ich seh das bei SWT/JFace schon richtig dass bei einem TableViewer der Adapter die ganzen Providers sind? LabelProvider,ContentProvider usw.

 

[Gast2]

Naja nicht ganz, wenn die View das Model kennt hat man dann eine schichtenübergreifende Kommunikation (was um himmelswillen nichts Schlimmes sein muss). Und du hast

Kannst auch mit MVC hinbekommen.

Also auf jeden Fall ist MVA eine Ableitung von MVC.

 

[ThreadPool]

Nun ja, das Modell könnte auch nur ein PresentationModel sein

Das hab ich mal als MVC mit Application Model kennengelernt und ist im Prinzip dieser Adaptergeschichte recht ähnlich, wobei der benötigte Teil des Domänenmodells dann ans Application Model geklinkt wird. Diese Variante des MVC kam übrigens auch schon Ende der Achtziger auf und ist auch noch heute in Gebrauch wie ich bestätigen kann da ich gerade vor so einem Stück Software sitze .

 

[André Uhres]

Also auf jeden Fall ist MVA eine Ableitung von MVC.

Das was hier unter "Modifying the MVC Design" erklärt wird, sollte dem MVA Muster entsprechen: Java SE Application Design With MVC

Gruß,
André

 

[Gast2]

Das was hier unter "Modifying the MVC Design" erklärt wird, sollte dem MVA Muster entsprechen: Java SE Application Design With MVC

Gruß,
André

Find ich auf jeden Fall besser als das ursprüngliche MVC...


Aber manche Änderungen werden immer noch an die View direkt gehen z.B. bei einem Databinding.

Ich würde auch kein ProperyChangeSupport mehr verwenden. Versteh nicht wann es Sinn machen könnte, dass eine View 2 oder mehr mals auf das gleiche Model hört. Und wenn dass schon geht sollten beim removeListener wenigstens wieder alle Instanzen gelöscht werden, was aber nicht passiert...

 

[ThreadPool]

Versteh nicht wann es Sinn machen könnte, dass eine View 2 oder mehr mals auf das gleiche Model hört.

Es soll tatsächlich Views geben die so groß sind und so schnell aktualisiert werden müssen das bei jedem Event vom Model ein komplettes Update langsamer ist als nur den Teil zu ändern der sich tatsächlich verändert hat. Das letzte Mal wo mir so etwas untergekommen ist war eine börsenorientierte Anwendung.

 

[Gast2]

Es soll tatsächlich Views geben die so groß sind und so schnell aktualisiert werden müssen das bei jedem Event vom Model ein komplettes Update langsamer ist als nur den Teil zu ändern der sich tatsächlich verändert hat. Das letzte Mal wo mir so etwas untergekommen ist war eine börsenorientierte Anwendung.

Ja??? Darum brauch die Views trotzdem keine 2 oder mehr PropertyChangeListener auf das gleiche Model. Genügt auch einer!!!

 

[FArt]

Kennt jemand eine Seite die überhaupt was über NVA...äh MVA weiß? Eine Begriffsdefinition, eine Beschreibung, ... sieht aus als wäre alles relevante in der Google-Welt (wenn es denn jemals existiert hat) in ein Wurmloch gerutscht...

 

[ThreadPool]

Kennt jemand eine Seite die überhaupt was über NVA...äh MVA weiß? Eine Begriffsdefinition, eine Beschreibung, ... sieht aus als wäre alles relevante in der Google-Welt (wenn es denn jemals existiert hat) in ein Wurmloch gerutscht...

Model View Adapter ist IMHO die selbe Interpretation wie Model View Presenter. Wobei ich hier Fowler meine GUI Architectures was auch eher die Idee bzw. die Essenz der Entwicklung des MVP bei Taligent und Dolphin beschreibt. Und das ist alles sehr identisch zum MVA (wenn man die spärlichen Quellen mal zusammensucht)