none
MVVM - Pattern - Verständnisfrage RRS feed

  • Frage

  • Guten Tag,

    Ich habe mir das MVVM-Pattern für WPF angeschaut und es schaut ja so aus, als ob es sich hierbei um einen möglichen Weg der Implementierung handelt. Also es haben sich Leute hingehockt und überlegt, wie eine WPF - Anwendung im Idealfall aussehen könnte.

    Ich habe mit diesem Konzept insgesamt keine Probleme, doch versuche ich zu verstehen, warum man die Objekte bzw. Daten und Listen aus der Geschäftslogik in das View-Model "duplizieren" muss, um es dann um UI-spezifischen Funktionen und Eigenschaften zu erweitern?

    Primär geht es doch bei diesem Mdell darum, Geschäftslogik und UI voneinander zu trennen und Codebehind zu vermeiden.  Warum muss ich nun meine Daten und Objekte duplizieren, um dieses Ziel zu erreichen. Das kostet mich noch nur mehr Zeit und Speicher. Der Vorwand dass man nur das dupliziert, was man für die Oberfläche braucht zählt für mich auch nciht, weil ich ja diese Entscheidung schon in der Geschäftslogik treffen muss. Ich hole sowieso nur die Daten aus der Datenbank, die ich für die Darstellung benötige. Mehr nicht. Stichwort Datenvirtualisierung.

    Ich kann doch genauso in meiner Geschäftslogik INotifyPropertyChanged und sonstigen Objekt-Erweiterungen implementieren, ohne dass es UI-Elemente beinhalten muss.

    Denke ich da falsch?



    Dienstag, 29. September 2009 06:32

Alle Antworten

  • Hallo A.R.

    Nein, du denkst nicht falsch, wenn du das Glück hast dass du deine Geschäftslogik um INotifyPropertyChanged erweitern kannst. Trotzdem wirst du ViewModel Instanzen brauchen die diese Objekte verwalten und als Property der UI zum Binden bereitstellen. In diesen ViewModels kannst du dann auch Commands anbieten um die Daten zu bearbeiten. Du musst auch irgendwann die Änderungen speichern oder verwerfen.

    Günter
    Dienstag, 29. September 2009 17:48
  • Ok. Ich verstehe den Sinn, warum noch eine zusätzliche Schicht benötigt wird. Als Beispiel sind auch die Commands zu erwähnen. Meine Meinung dazu:

    Das ist sehr wohl abzuwägen, ob man und vor allem wie man sein View-Model implementieren soll. Grundsätzlich bin ich der Meinung dass das Kopieren von Daten in das View-Model der falsche Ansatz ist und auch nicht wirklich praktikabel

    Stattdessen könnte man die Geschäftslogikklassen um die WPF-Spezifischen Schnittstellen erweitern und gut ist. Ein Command-Property lässt sich auch ohne WPF gut anwenden, genauso wie INotifyPropertyChanged usw.

    Oder so eine Art UI-Interop mit dem Verweis auf das Orginal-Objekt oder so ähnlich.

    Mittwoch, 30. September 2009 07:12
  • Einer der wichtigsten Gründe für ViewModels ist das man sie testen kann. Je mehr du in CodeBehind abwickelst um so weniger kannst du testen.
    Mittwoch, 30. September 2009 07:18
  • ja ok. doch Code-Bedind ist ja nach Möglichkeit gänzlich zu vermeiden.

    Also die Geschäftslogik, kann so implementiert sein, dass ich sie ohne größere Probleme mit der UI "verheiraten" kann - ohne Code-Behind versteht sich - .  Also eine Geschäftslogik mit Commands und INotifyPropertyChanged und IDataErrorInfo usw. Diese Konzepte sind ja primär UI-Unabhängig.

    Warum ich also in MVVM-Pattern das Viewmodel benötige ist mir vollkommen schleierhaft. Auch der Umstand dass ich meine Daten zum Teil duplizieren muss, macht es nicht einfacher zu verstehen.

    Donnerstag, 1. Oktober 2009 08:19
  • Was löst bei dir eine Verdoppelung der Daten aus? Hast du ein konkretes Beispiel anhand dessen wir dein MVVM Verständnisproblem anschauen können?

    Donnerstag, 1. Oktober 2009 08:38
  • Laut MVVM muss man die Daten der Geschäftslogik in das VIEWModel kopieren. So machen es auch sämtliche Beispiele nach:

    Siehe auch http://dotnet-gui.com/forums/t/216.aspx

    Ich verstehe nicht, warum ich meine Daten kopieren muss.  :)
    Donnerstag, 1. Oktober 2009 09:48
  • Entschuldige ich seh immer noch nicht wo hier Daten kopiert werden. Es wird ja nur ein Wrapper (ViewModel) um die Person gestülpt. Ein Person Objekt gibt es nur einmal pro ViewModel.

    Du kannst am ViewModel ein Property Person implementieren, weil du ja das INotifyPropertyChanged selbst implementierst.
    Donnerstag, 1. Oktober 2009 10:04
  • Genau das ist der Punkt. Die Daten werden nicht dupliziert, jedoch baut der Entwickler in diesem Beispiel eine Interop-Klasse, was die Geschäftslogik-Klasse genauso implementieren muss. auch wenn er die Daten aus der Geschäftlogik nur weiterreicht, verstehe ich nicht, warum ich diesen Mehraufwand betreiben muss.

    Wichtig ist ja dass die zustandsbehaftete Geschäftslogik UI-Unabhängig implementiert wird und keine UIElemente beinhaltet. Command Klassen und Implementierung der notwendigen Schnittstellen für DataBinding stehen für mich NICHT unter dieser Kategorie. Das sind notwendige Erweiterungen, die man auch ohne WPF nutzen kann. Genauso bin ich der Meinung dass man die Validierungsregeln auch in der Geschäftslogik implementieren sollte, da diese unabhängig von der UI gelten sollten. Eine zusätzliche Schicht für diese Erweiterungen ist nicht unbedingt notwendig?
    • Als Antwort vorgeschlagen ChrDressler Samstag, 10. Oktober 2009 10:25
    • Nicht als Antwort vorgeschlagen A.R. Germany Montag, 12. Oktober 2009 08:32
    Donnerstag, 1. Oktober 2009 14:26
  • Hallo A.R.,

    der Antwort-Vorschlag war versehentlich, kann ich aber nicht löschen....

    Ich verstehe deine Verwirrung, mir geht das auch so. Ich komme aus einer Welt (Foxpro), die diese extra Zwischenschicht nicht braucht und es dennoch ermöglicht, gute, testbare Programme / UIs zu schreiben. Das Argument der besseren Testbarkeit und des Abtrennung des Designs der UI ist sicher richtig. Für Projekte, die von kleineren Teams (3-5 Entwicker) gestemmt werden müssen, erzeugt das aber einen derartigen Infrastuktur-Overhead, dass ich auch eine Problem mit dem Thema habe.
    Alle dieser intere Aufwand wird vom Kunden nicht bezahlt.
    Die Diskussionen in div. Foren scheinen mir öfter vor akademischen Hintergrund stattzufinden. Das Wort Liefertermin ist sehr selten...

    Auf den anderen Seite ist in der Tat der Zeitgeist und damit sämtliches Material auf das MVVM der reinen Lehre fixiert, so dass es wohl besser ist, sich mit dem Thema zu beschäftigen.
    Irgendwann hat man ein ein eigenes Anwendungsframework und die Arbeit wird hoffentlich wieder rationeller.

    Ich kann nur sagen, dass meine Produktitität trotz monatelanger Beschäftigung mit WPF noch sehr weit von der in der VFP-Welt entfernt ist. Auch wegen Know-How, aber vor allem wg. der vielen Schreibarbeit und dem physischen und gedanklichen Navigieren zwischen den Schichten.

    Im übrigen werden Daten nie kopiert, es immer dasselbe Objekt nur hinter verschiedenen Wrappern. Der Arbeitsspeicher ist damit weniger das Problem. Allerdings muss ja igendeiner diese vielen Wrapper verwalten (CPU). Aber was solls, bei den vielen GHz heute...

    -christoph
    Samstag, 10. Oktober 2009 10:45
  • Hallo Christoph,

    ich war auch bei paar Seminaren diesbezüglich dabei und es kommt mir einfach so vor, als ob die Befürwörter dieser zusätzlichen Schicht nicht wirklich wissen, warum bzw. sich nicht wirklich darüber ihre GEdanken machen.

    Ich habe mit der Zeit gerlernt, dass der Arbeitsspeicherverbrauch enorm wichtig ist. Wenn ich eine gute Software liefern soll, darf er nicht viel Arbeitsspeicher brauchen. Microsoft hat in diesem Bereich stark aufzuholen. Es kann einfach nicht sein, dass ein mit zwei Buttons und ein Textbox bestücktes Windows Form Formular ohne Code gute 10 bis 12 MB Arbeitspeicher für sich reserviert.

    Ich finde es richtig und wichtig, dass man die Software logischa auftreilt und auch die Trennung zwischen UI und Geschäftslogi ist meines Erachtens ein MUSS, doch sind bewusste Abweichungen von der strikten Theorie, wenn es dem Hauptzweck dienen sollte das Programm performanter und schneller zu machen, sind meines Erachtens durchaus erlaubt.



    Montag, 12. Oktober 2009 08:30
  • Hallo ChrDressler,

    ich verstehe, dass man diese Wrapper benötigt, wenn man keinen Einfluss auf die Datenobjekte hat und diese nicht die Schnittstelle INotifyPropertyChanged implementieren. Der Ansatz des Wrapper hat für mich diverse Nachteile:

    • Implementiert das Datenobjekt INotifyPropertyChanged, werden die Änderungen am Datenobjekt nicht auf der Oberfläche weitergereicht. Hierrfür müsste das ViewModel ebenfalls auf die Ereignisse horchen und die weitergeben - was wiederum mehr Aufwand bedeutet.
    • Viele Eigenschaften müssen einfach nur durchgereicht werden (Wrapper) was unnötig viel schreibaufwand bedeutet - ein Mehrgewinn ist m.E. auch nicht zu erkennen (solange das Datenmodell kein INotifyPropertyChanged implementiert)
    • Was passiert, wenn man im ViewModel auf mehrere (Data) Models zugreifen muß? Namenskonflikte können leicht entstehen

    Die Hauptaufgabe des ViewModels besteht doch darin, ein Model für die View zu sein - die View muss also lediglich über Datenbindungen auf das ViewModel zugreifen. Und das müssen nicht nur reine Nutzdaten sein:

    • Wird ein anderes Format oder ein berechneter Wert benötigt, kann diese vom ViewModel zur Verfügung gestellt werden
    • Zugriff auf Kommandos
    • ProgrammLogik für die UI

    Hat man Einfluss auf das Datenmodell, würde ich immer die Implementierung von INotifyPropertyChanged bevorzugen. Dann muss im ViewModel lediglich eine Eigenschaft pro Data Model implementiert werden.

    public class CustomerViewModel
    {
      // ...
      public CustomerDataModel Customer { get; }
    }

    Oder wie seht ihr das?

    Donnerstag, 25. Februar 2010 08:40