# MVC vs MVA



## Gast2 (3. Dez 2010)

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 (3. Dez 2010)

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 (3. Dez 2010)

ThreadPool hat gesagt.:


> 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 (3. Dez 2010)

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 (3. Dez 2010)

SirWayne hat gesagt.:


> 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 (3. Dez 2010)

> 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 (3. Dez 2010)

maki hat gesagt.:


> 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 (3. Dez 2010)

ThreadPool hat gesagt.:


> 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 (3. Dez 2010)

maki hat gesagt.:


> 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 (3. Dez 2010)

SirWayne hat gesagt.:


> 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 (6. Dez 2010)

André Uhres hat gesagt.:


> 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 (6. Dez 2010)

SirWayne hat gesagt.:


> 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 (6. Dez 2010)

ThreadPool hat gesagt.:


> 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 (6. Dez 2010)

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 (6. Dez 2010)

FArt hat gesagt.:


> 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)


----------

