Warum MVVM-Pattern?

[Smart]

Hallo Forum,

ich hätte da eib paar verständnisfragen. Ich hoffe, ihr könnt mir dabei helfen:
Ich weiss, dass MVVM ein Ansatz ist, der vor allem speziel für Silverlight entwickelt wurde. Meine Fragen sind diesbezüglich wie folgt:

1. Was ist da der Unterschied zu anderen MV-Pattern?
2. Warum kann man da nicht z.B. von MVC Gebrauch machen (z.B. bezüglich WPF und data-binding)?
3. Gibt es da bei den anderen MV-Pattern Einschräkungen, die MVVM an dieser Stelle nicht hat?
3. Welche andere MV-Pattern gibt es, die man eventuell einsetzen könnte?

Danke im Voraus.


Gruß

[fanderlf]

Mh... ich bin da auch kein großer Experte, aber ich glaub ich habs so verstanden:

MVC hat von Haus aus erstmal gar kein DataBinding. Der Controller macht die Kommunikation zwischen Modell und View, also praktisch das DataBinding. Das ist praktisch manuelles DataBinding.

In MVVM macht man massiv Einsatz vom DataBinding des WPF Framework. Das ViewModel kommuniziert mit dem Modell und stellt daraus Properties zur Verfügung die in der View gebunden werden.

Du kannst natürlich auch MVC in WPF machen. Dann benutzt du von WPF nur noch das Zeichnen der Controls nicht aber das DataBinding. Für grafisch komplexe Views kann es durchaus auch Sinn machen so etwas neben MVVM zu machen. Empfehlen würde ich es allerdings nicht, denn WPF nimmt Dir an dieser Stelle wirklich viel Arbeit (z.B. Stichwort INotifyPropertyChanged, INotifyCollectionChanged)

[Ralf Jansen]

1. Was ist da der Unterschied zu anderen MV-Pattern?

Alle MV-Patterns versuchen einen View mit einem Model zusammenzubringen ohne sie zu eng zu koppeln (darum ist der MV Teil im Name ja auch immer konstant) ob da zusätzlich jetzt ein Controller, Presenter, ViewModel zwischen hängt ist meiner Meinung nach mehr philosophischer Natur und die Übergänge meist fließend. Ich könnte jetzt irgendwelche Wikipedia Artikel wiederholen aber das würde nichts verdeutlichen. Außerdem hast du die sicher schon selbst gefunden.

2. Warum kann man da nicht z.B. von MVC Gebrauch machen (z.B. bezüglich WPF und data-binding)?

Kann man. Aber WPF ist um ein spezielles Pattern herumgeschrieben dem man den Stempel MVVM gegeben hat. Wenn man sich daran hält und den ausgetretenen Pfad verwendet tut man sich meist einfacher.

3. Gibt es da bei den anderen MV-Pattern Einschräkungen, die MVVM an dieser Stelle nicht hat?

Ich persönlich würde zwischen den meisten der MV-Patterns keinen qualitativen Unterschied machen. Je nach Problem und beteiligten Programmieren bietet sich das ein oder andere Muster eher an. Und das gibt es natürlich noch die Systeme die ein bestimmtest Muster bevorzugen wie eben WPF weil sie es schon selbst implementieren oder zumindest darauf vorbereitet sind.

3. Welche andere MV-Pattern gibt es, die man eventuell einsetzen könnte?

Bist du Asiat da du scheinbar eine Abneigung gegen die 4 hast
Es gibt MVC, MVP, MVM. MVP noch dazu in diversen Varianten als Active View, Passive View, Supervising Controller und noch ein paar mehr.


Wenn bei dir aber WPF und Databinding schon als technologische Kerntechniken gesetzt sind macht es eigentlich keinen Sinn über was anderes als die enthaltene MVVM Variante nachzudenken. Eher ob man sich dazu nicht noch einen technologischen Überbau ranholt wie zum Beispiel Prism

[Smart]

Hi,

vielen Dank. Ich vertehe. Wenn es aber keine data-binding gibt. Wie wird bei MVC dann die Kommunikation zwischen Code und View durchgeführt? Im Code-Behind? Und was ist mit MVP?

Gruß

[Smart]

Hallo Ralf,

vielen Dank für die Schilderung der Sachlage. Ich kann mir nun besser vorstellen, wie die Zusammenhänge sind. Was ist mit dem zweiten MVP im letzten Satz gemeint? Du bist doch nicht Asiat?

Gruß

[Ralf Jansen]

vielen Dank. Ich vertehe. Wenn es aber keine data-binding gibt. Wie wird bei MVC dann die Kommunikation zwischen Code und View durchgeführt? Im Code-Behind?

Allgemein beantwortet :

Deine UI und der Codebehind dazu sind beides Teil des View. Was du innerhalb des Views technologisch anstellst ist dem Pattern egal. Das regelt nur die Verteilung der Aufgaben und Problematisch ist Technologie die zwischen View und ViewModel verwendet wird. Da sollte man sich auf schlichte Methodenaufruf und Events über Interfaces reduzieren. Da kann man aber natürlich auch Databinding verwenden. Es wiederspricht eben nur dem Gedanken die nicht eng zu koppeln. Es geht ja nur um Patterns also um Ideen da gibt es keine technologischen Grenzen die irgendwas verhindern.

Auf WPF bezogen:

MVVM Pattern und spezielle WPF Features sind hier so miteinander verwurschtet das es nichts bringt sich gegen WPF Spezialitäten zu stemmen um der hohen Lehre des Patterns zu folgen. WPF wirst du eh nie in einer Weise los so das die Anwendung mit MVVM Pattern aber ohne WPF weiter weiterverwendet werden könnte. Abgesehen von der Möglichkeit ein anders selbstgestricktes MVVM Pattern über das von WPF zu legen. Gefühlt hört sich das aber nach einem Knieschuss an.

Was ist mit dem zweiten MVP im letzten Satz gemeint?

Im letzten Satz steht was von MVP?

[Smart]

Hallo Ralf,

danke. Aber wenn man sich bei MVC auf Methoden-Aufrufe reduzieren würde, um z.B. etwas in View zu verändern, macht die Trennung von View und logik nicht mehr viel Sinn. Weil man, wie es scheint, ohne data-binding nur über methoden des code-behind an View daran kommen könnte.

Gruß

[Ralf Jansen]

Aber wenn man sich bei MVC auf Methoden-Aufrufe reduzieren würde, um z.B. etwas in View zu verändern, macht die Trennung von View und logik nicht mehr viel Sinn. Weil man, wie es scheint, ohne data-binding nur über methoden des code-behind an View daran kommen könnte.

Ich rede von der Kommunikation zwischen View und Controller, Presenter, ViewModel oder setzteHierObjectNameDeEinerWahlEin im allgemeinen Pattern. Du von der Kommunikation zwischen Codebehind und der UI speziell in der MVVM Umsetzung in WPF. Wenn ich das Pattern implementieren müsste sollte niemand was von WPF und XAML wissen außer dem View. Das ist einer der Hauptzwecke dieser Patterns den Rest von der UI Technik zu entkoppeln. Diese Trennung mag in WPF nicht so deutlich ausgeprägt sein (ich sprach glaube ich schon von verwurstet) und ist in MVVM zugegebenermaßen auch etwas weniger relevant sein in den anderen MV Patterns. Wenn du dem Pattern folgen willst und die UI Technik dem unterordnest dann Methoden und Events. Wenn du WPF machen willst und das Pattern unterordnest dann eben auch Databinding zwischen ViewModel und View und allen Features die WPF hergibt. Auch wenn sich WPF den Stempel MVVM gibt und die Dinge so benennt heißt das nicht das es dem Pattern besonders stringent folgt. Ich empfinde WPF an der Stelle sogar eher paradox da es eine Pattern zur UI-von-Logik Entkopplung hart an eine spezielle UI Technik koppelt.

Vielleicht solltest du bevor wir hier weiter diskutieren klarstellen was dein Ziel ist. Ein Verständnis des Patterns und Unterscheidung dieser im Allgemeinen oder was man am Geschicktesten ganz speziell in der kleinen WPF Welt machen kann.

[Smart]

Ich möchte gerne wissen, wie man begründen kann, warum man im Allgemein z.B. bei XAML bevorzugt von MVVM Gebrauch machen soll und nicht von anderen Patterns wie mvc oder pmp. Ich weiß nicht, ob man das nur deswegen macht, weil da einem die Möglichkeit der data-binding zur Verfügung steht, obwohl das alleine das Leben leichter machen würde.

[Ralf Jansen]

Databinding ist mit jedem Pattern (mal unabhängig davon ob ich das persönlich für gut oder schlecht halte) möglich das war also sicher kein zwingender Grund das sich Microsoft entschieden hat dieses Pattern zu benutzen. Vielleicht weil man bei den anderen Patterns leichter auf die Idee kommen könnte View und Model direkt zu binden. Auch wenn das Binden aus dem Controller/Presenter heraus passiert sicher eine schlechte Idee. Oder einfach nur weil das MVVM Pattern die aktuellste Inkarnation der MV Patterns ist. Reine Spekulation.

Wenn du Lust hast den Grund zu erforschen wäre die patterns&practises Leute bei Microsoft ein guter Anlaufpunkt oder ganz allgemein die Microsoft Blogs.

[fanderlf]

Was ich an dieser Stelle noch anbringen möchte:

Patterns sind nicht in erster Linie dazu da um reinem Dogmatismus zu folgen. Patterns sind also nicht in erster Linie "ideale" Lösungen. Erstmal sind Patterns Strukturen die wiederkehrend in Software zu finden waren. Heisst es war nicht erst das Pattern da weil sich das jemand ausgedacht hat, sondern zuerst war Code und jemand hat festgestellt, dass dasselbe Probleme in verschiedenen Softwareprojekten immer auf ähnliche Art und Weise gelöst wurde. Das ganze wurde dann vereinheitlicht und dem ganzen ein Name gegeben.

Man sollte sich deswegen auch nicht zu sehr darauf versteifen unbedingt irgendwelche Patterns benutzen zu müssen. Hat man die Patterns verstanden dann werden diese mit der Zeit wie von selbst in deinem Quellcode auftauchen ohne dass Du das wirklich vor hast. Später wirst Du erkennen, dass das jetzt dieses und jenes Pattern ist.

Mach die Lösung so wie es
a, für Dich am einfachsten ist
b, Du am schnellsten zum Ergebnis kommst
c, die Lösung erfordert

Dogmatismus und verfrühte Generalisierung sind der absolute Zeit- und Qualitätskiller.