INotifyPropertyChanged WPF(MVVM)

Question

Hallo zusammen,

derzeit finde ich keine plausible Antwort hinsichtlich wer die INotifyPropertyChanged-Schnittstelle implementieren sollten. Mal wird das Model, mal das ViewModel angeführt. Hinsichtlich der Validierung müsste sie eigentlich vom Model implementiert werden. Will man aber die View auch über Änderungen an Eigenschaften des ViewModel die nichts mit dem Model zu tun haben informieren, müsste das ViewModel die Schnittstelle auch implementieren. Dies wäre dann aber doppelt. Sowie das Model als auch das ViewModel würden Änderungen am Model detektieren.

Etwas verwirrt und ratlos.

Danke für jeden Tipp

Gruß Scotty

Answer 1

Hi Scotty,

grundlegend ist die Schnittstelle ja beim Databinding interessant um die UI upzudaten. Also solltest du es in die Klassen Implementieren, die du Bindest, wenn nötig auch in beiden. 

Wenn du ganz "konzequent" nach dem MVVM Pattern geht sollte nur das VM das Model kennen und alle Änderungen über das VM laufen, also braucht eigendlich nur das VM die PropertyChange Schnittstelle.

Es gibt aber auch durchaus Senarien bei denen es sinfoll ist das Model direkt an die UI zu binden, hier muss dann das Model auch die Schnittstelle Implementuieren. Es kann auch sein das du keine Eigenschaft die sich änder vom VM an die View bindest. Dann brauch das VM auch ein Property Chnage.

Grundlegend bei kleineren Projekten. Wenn du es nicht brauchst implementier es nicht. Wenn du es brauchst implementier es egal ob im VM oder Model.

Bei größeren Projekten möchtest du hier vielleicht lieber ein allgemein gleiches Verhalten einführen (z.B. mit einer gemeinsamen BasisKlasse) Hier ist dann die Frage was dir wichtiger ist. Die strikte Trennung von View und Model oder die Möglichkeit bei bedarf an die View zu binden. 

MFG

Björn

Answer 2

Hallo Björn,

ich glaube es ist der falsche Ansatz wenn man dem Model direkten Zugriff auf UI gewährt, andersrum genauso. Das wiederspricht einfach dem MVVM-Pattern. Dementsprechend reicht es vollkommen wenn das ViewModel INotifyPropertyChanged implementiert. Ich kann mir derzeit kein Szenario vorstellen, warum es anders sein sollte. Alleine dass das Model noch nicht einmal das ViewModel kennen sollte, müsste als Argumentation ausreichen.

Ich lasse mich gerne belehren, aber dann auch mit einem praktischem Beispiel. Und ich bin mir fast sicher das man ein solches Szenario wieder so abbilden kann, dass lediglich das ViewModel mit der View(UI) kommuniziert und nicht das Model.

Für weitere Meinungen bitte ich gerne offen.

Gruß Scotty

Answer 3

Hallo Scotty,

dass das Model die View oder das VM kennen soll, hab ich nicht gesagt. Wenn das Model die UI aktualisiert wenn das PropertyChange Event geschmissen wird, kennt das Model nicht die View. Grundlegend handelt es sich hier um das Beobachter muster.

Das VM sollte auch nicht die View kennen.

Das was ich meinte ist das die View das Model kennt.

Ein Beispiel bei dem ich es praktisch Verwende ist für ein Rollenspiel (AD&D), welches ich spiele ein Programm zum Suchen und Anzeigen von Zaubern. In den Büchern zu suchen war immer recht aufwändig und stat 8 Büchern schleppe ich jetzt einen Labtop mit mir rum. Und da binde ich direkt die Zauber ans Datagrid View und in der Detail Ansicht. Die View kennt also das Model (Zauber), da noch ein ViewModel für den Zauber zu erställen wäre natürlich Möglich gewesen. Mehr Code schreiben als man muss kann man immer, aber wie so sollte man?

MFG
Björn

 

Answer 4

Hallo Björn,

entweder habe ich das MVVM-Pattern falsch verstanden oder Du. Ich gehe mal vom Letzteren aus. Weder die View darf das Model "kennen", noch das Model die View. Interaktionen zwischen  Model und View finden nur über das ViewModel statt. Das grundsätzliche Prinzip besteht darin, das für jedes Model ein ViewModel zu erstellen ist. Letzteres wird dann an die View gebunden. Nur so gann sicher gestellt, das die View jederzeit ausgetauscht werden kann ohne das etwas am Model geändert werden muss. Gleiches gilt natürlich auch dass Model geändert wird und die VIew weiterhin funktioniert.

Sorry, aber ich hätte mit einem praktischerem Beispiel gerechnet.

Nun trotz aller dem sehe ich keine Notwendigkeit INotifyPropertyChanged ins Model zu implementieren.

Gruß Scotty

Answer 5

Hallo Scotty,

wie ich oben gescchriben habe:

Wenn du ganz "konzequent" nach dem MVVM Pattern geht sollte nur das VM das Model kennen und alle Änderungen über das VM laufen, also braucht eigendlich nur das VM die PropertyChange Schnittstelle.

Was deinem Verständnis villeicht ein bisschen auf die sprünge helfen kann, ist der Orginal Blog eintrag von John Grossman (Erfinder MVVM Pattern). Wo er das schreibt.

In simple examples, the View is data bound directly to the Model.  Parts of the Model are simply displayed in the view by one-way data binding.  Other parts of the model can be edited by directly binding controls two-way to the data.  For example, a boolean in the Model can be data bound to a CheckBox, or a string field to a TextBox.

Wenn ich das Model an die View binde sollte das Model auch ein INotifyPropertyChanged Implementieren.

MFG

Björn

Answer 6

Hallo Björn,

wenn Du schon Beiträge anführst sollest auch verstehen was Auto mein. Hier sag Er nur aus das normalerweise("simple") die Datenquelle an die UI gebunden wird. Genau dieses soll mit dem MVVM-Pattern nicht passiern.

Schaust Du hier:

http://www.youtube.com/watch?v=BClf7GZR0DQ

Hier versucht Joel zu erklären warum die View nichts mit dem Model zu tun hat.

Gruß Scotty

Answer 7

Nun da gib ich dir recht es es hilf zu verstehen was der Autor meint.

Und wenn ich für Simple das doch sehr gebräuchliche „einfach“ nehme.

Bekomme ich die Aussage. Das in einfachen Beispielen, die Daten einfach an die UI gebunden werden. Ich aber in der Realität meistens noch eine Form von Logik da hinter habe und ich die Daten nicht so einfach an die UI binden kann. Und ich die Logik in das VM packe. Klingt gut für mich.

Wenn ich jetzt Normal nehme bekomme ich raus: Das normale Beispiele nicht real sind. Klingt komisch.

MFG

Björn

Answer 8

Hallo Björn,

ich habe mich sicherlich zu schlicht ausgedrückt. ;=)

Wenn Du eine WindowsForms-Anwendung hast bleibt Dir nichts anderes über als die Datenquelle direkt an die UI zu binden. Die gesamte Logik zum Validieren, Speichern etc. befindet sich dann in diesen beiden Komponenten. Eine Geschäftslogik kann dieses dann etwas entschärfen. Der Zusammenhang zwischen Datenquelle(Model) und UI(View) ist aber vorhanden.

Entwickelt man strikt nach dem MVVM-Pattern entsteht der Zusammenhang nicht. Ich persönlich empfinde es als äußert praktisch eine strikte Trennung zu haben. Auf der einen Seite kann der Entwickler die Logik und Datenquelle bearbeiten und auf der anderen Seite der Designer(Person) sich um die Oberfläche kümmern.

In dem Video kann man sehr schön die Trennung sehen. Der Entwickler benutzt VS, der Designer hingegen Blend. Letztendlich wird alles nur zusammengebunden.

Nur sollte man verstehen wie sich hier bspw. INotifyPropertyChanged auf das Pattern auswirkt. Ein weitere Schnittstelle wäre IDataErrorInfo, hier habe ich aber noch keine Möglichkeit gefunden sie aus dem Model ins ViewModel zu verschieben.

Gruß Scotty

Answer 9

Hi Scotty,

da ich heute Arend ein wenig Zeit habe, gebe ich einfach mal eine Antwort. 

Grundlegend sind wir uns ja einig und ich denke an den Punkten wo wir uns uneinig sind gibt es einfach nur ein Kommunikationsproblem. Was sicher an mir und meiner Rechtschreibung liegen kann.

Was Win Forms und MVVM angeht, man kann das Pattern auch dort Anwenden, es macht einfach nur mehr Arbeit als bei WPF. Dafür hast du aber wider eine saubere Trennung und kannst bei bedarf die Oberfläche relative einfach austauschen. 

Die Trennung zwischen Entwickler und Designer, ist meines Erachtens relativ unwichtig. Da es oftmals in einer Person fällt. An dem Punkt ist es wichtiger die Logik von der Oberfläche getrennt zu haben um sie Testen zu können. Dann macht es auch keinen Unterschied mehr aus ob Entwickler und Designer getrennt sind.

An den Punkt möchte ich einfach anmerken ich bin ein Riesen Fan von Pattern, seit ich das Buch der GoF gelesen habe. Da wurde mir ein standard Lösungsweg für viele Probleme geboten.

Der grundlegende Sinn von Pattern ist es einen Lösungsweg für Probleme zu bieten. Und nicht seine Probleme in den Lösungsweg zu Zwängen.

Mit freundlichen Grüßen

Björn

Answer 10

Hallo Björn,

Deine Aussagen kann ich nur teilweise teilen. Was WinForms und MVVM betrifft. so glaube ich nicht dass es so realisierbar ist, dass es überhaupt noch Sinn macht. Klar sollte die UI von der Logik getrennt sein, doch sei doch mal ehrlich, gelingt Dir die strikte Trennung immer? Ich denke da nur an das "Enablen/ Disablen" von Controls.

Nächster Punkt wo wir ehrlich sein sollten. Wenn Du oder ich eine Anwendung erstellen, dann soll sie praktisch sein. Wenn ich schön sein wollte wäre ich Dressman oder Model geworden und nicht Soft- und Hardware-Entwickler. Schau Dir doch mal Software an. Es gibt welche die sehen unheimlich geil aus, taugen für die Aufgabe nicht im Ansatz. Anders gibt es Software die macht alles mögliche was Du mit der Problemstellung in Verbindung bringen kannst, aber die Oberfläche ist der maß komplex dass sie nur bedingt bedienbar ist. Der Entwickler hat damit kein Problem weil Er genau weiß welche "Knöpsche" er drücken muss um ans Ziel zu kommen.

Was ich damit sagen will ist sehr schön wenn man das Design von der Logik trennt. Somit kann der Designer mit Styles und Templates rumspielen ohne dass der Entwickler darauf Rücksicht nehmen. Anders rum kann der Entwickler an seiner Logik basteln ohne dass dem Designer dadurch Probleme entstehen.

Ich habe mehrere Kunden da wird genau das praktiziert - Design von der Entwicklung trennen. 100% funktioniert das nie - Logisch, woher soll der Designer wissen welche Daten es gibt? Andersrum woher soll der Entwickler wissen welche Daten zur Ansicht/ Bearbeitung bereitgestellt werden müssen?

Dein letzten Absatz finde ich sehr treffend. Erst muss das Problem her und dann suchen wir eine Lösung und nicht wir haben eine Lösung, die müssen wir nur auf das Problem anwenden. Vielleicht ein Beispiel aus der Hardware:

Zur Kommunikation einer Hardware benutze ich eine(oder mehrere) USB-Schnittstelle(n). Viele MCU's haben aber nur eine UART Schnittstelle. Um nun die Umsetzung zu erreichen benutze ich einen FTDI FT232R. Dieses Bauteil kann aber mit verschieden Varianten der Spannungsversorgung ausgestattet werden. Zu einem gibt es die Möglichkeit der "Bus-Powered-Configuration". Sehr praktisch wenn die nachfolgende Schaltung nicht sehr viel Strom braucht und keine externe Spannungsversorgung benötigt. Die Versorgung der gesamten Schaltung findet dann mittels der USB-Schnittstelle statt. Eine andere Variante ist die "Self-Powered-Configuration". Logischerweise wird die Variante dann benutzt wenn die Stromversorgung der USB-Schnittstelle in Sachen Spannung/ Strom nicht mehr ausreicht. Der Baustein wird dann mit von der externen Spannungsversorgung beschaltet.

Wenn ich jetzt also nur eine der Lösungen kennen würde, dürfte die nachfolgende Schaltung immer in die maximale Versorgung der USB-Schnittstelle fallen oder ich müsste grundsätzlich eine externe Spannungsversorgung vorsehen. Dies würde dann in die Kategorie "Ich habe eine Lösung, das Problem muss aber muss aber in die Lösung passen."

Auch hier kannst Du ein Muster sehen. Du hast ein Model(die Daten der USB-Schnittstelle), eine View(die Eingänge/ Ausgänge der nachfolgenden Schaltung) und ein ViewModel(die Schaltung inkl. der Spannungsversorgung). Alleine durch die Anpassung des ViewModel kann ich entscheiden ob es eine interne oder externe Spannungsversorgung gibt. Weder die Kommunikation mit der USB-Schnittstelle noch die Ein- und Ausgänge der Schaltung sind davon betroffen.

Gruß Scotty

Answer 11

Hi Scotty,

MVVM mit Windows Forms umzusetzen ist jetzt nicht wirklich so kompliziert. Schau mal hier und wenn du googlest findest du etliche Beispiele.

Wenn für dich der Desinger der grund ist das du MVVM verwendest ist das für mich vollkommen in Ordnung. Für mich ist es die Testbarkeit. Aber wir bekommen ja beide was wir wollen. :)

MFG

Björn

 

Answer 12

Hallo Björn,

genau dort das liegt das Problem, dass man falsch verstehen kann. Der Autor kennt das ViewModel und seiner Codebehind-Source. Hältst Du Dich strikt an WPF mit MVVM benötigst Du nicht eine Codezeile in der View. Daher ist das Austauschen/ Ändern der View auch nicht mehr ein Problem des Entwicklers. Dies ist für mich entscheidend warum ich diesen Ansatz verfolge. In der Hardware ist es ähnlich nur kann man hier Grenzen noch deutlicher sehen. Es wird ein Protokoll vereinbart wie der PC mit der Hardware kommunizieren hat. Das war es - Ich muss also nicht wissen wie irgend etwas angesteuert wird. Wenn ich einer CNC sage verfahre die X-Achse um 8,75mm muss ich nicht wissen wie das intern in der Schaltung gelöst ist. Und wenn von dort ein Meldung kommt "Bin auf Anschlag", interessiert mich das auch nicht, welche MCU die Warnung generiert hat. Ich habe also ein strikte Trennung. Auf der anderen Seite ist es genauso, die Maschine schreibt vor was sie wie kann. Im einfachsten Fall ist das eine Schrittmotorendstufe mit angeschlossenen Schrittmotor. Dabei interessiert es mich nicht wie Groß das Drehmoment des Motors ist.

Genauso ist es auch in reinen Software-Projekten. Deine UI kann ein "normales Programm" sein oder eine Web-Anwendung. Ob die Anbindung zu einer SQL oder Oracle-DB stattfindet interessiert dabei nicht.

Gruß Scotty

Answer 13

Hi Karsten,
mit Deinen Argumenten bin ich nicht vollständig einverstanden.

MVVM ist kein Dogma und sollte schöpferisch angewandt werden. Hauptziel sollte die Testbarkeit des ViewModels und des Models sein. Die Geschäftslogik kann da vollständig von der UI getrennt werden. Problematisch kann es nur werden, wenn Bedientechnologie und Geschäftslogik nicht sauber getrennt sind. Die Bedientechnologie erfordert u.U. auch Logik in der Oberfläche, die mit der Geschäftslogik nichts zu tun hat. In diesem Fall kann oder sollte man nicht den gesamten Code in den ViewModel auslagern. Das kann insbesondere in WindowsForms erforderlich werden. In WPF kann man mit den umfangreicheren Bindungsmöglichkeiten, entsprechenden Konvertern und Styles mit Storyboard meist ohne CodeBehind in der UI auskommen.

Die Beziehung ist üblicherweise eine Einbahnstraße. Den Entwickler des ViewModels interessiert überhaupt nicht, was der Designer anzeigen will. Für ihn ist lediglich die spezifizierte Geschäftslogik umzusetzen. Der Designer kann aber nur das nutzen, was der ViewModel bereitstellt. Da kann es bei schlechtem Pflichtenheft passieren, dass sich Designer und ViewModel-Programmierer nachträglich zusätzlich abstimmen müssen.

Auch, wenn Dein USB-Gerät viele Funktionalitäten liefert, so muss der Model nur das implementieren, was entsprechend Pflichtenheft erforderlich ist. Auch der ViewModel kann nur auf das zugreifen, was der Model liefert, gleichfalls die UI. Wenn das nicht schlüssig spezifiziert ist, dann entsteht der von Dir skizzierte Zustand für zusätzlichen Abstimmungsbedarf.

--
Peter

Answer 14

Hallo Peter,

Du sprichst wieder von Testbarkeit, das Szenario wie ich es beschrieben habe ist gegen alle Komponenten testbar ohne das jemand weiß weis was der andere kann oder tut. Ich kann das VM gegen ein Softkomponente austauschen und ich könnte die View testen. Ich kann die View tauschen ohne dass das VM geändert wird. Ich kann das Model austauschen ohne das VM zu ändern, andersrum natürlich genauso. Nehme ich aber Änderungen vor. so muss mein Gegenüberpart(Entwickler oder Designer) informiert werden, dass es neue/geänderte Methoden oder Eigenschaften gibt. Die Kommunikation bleibt also nicht aus, und das ist auch gut so.

Du sprichst von einer Einbahnstraße, dem wieder spreche ich. Es gibt nichts schlechteres wenn man nicht weiß ob eine Aktion ausgeführt wird oder ausgeführt wurde. "Steht die Maschine jetzt, oder tut sie noch was? - Mal abwarten wenn sie in 2 Stunden immer noch mit laufenden Motor da verharrt wird sie wohl fertig sein".  Wenn ich also nicht weiß wie die Rückmeldung zu beurteilen ist oder sie nicht anzeige, hat der Anwender ein Problem.

Dieses kann ich aber sauber trennen wer was zu tun hat.

Gruß Scotty

Answer 15

Hi Karsten,
mit Testbarkeit meine ich vor allem UnitTests, die automatisch beim Einchecken oder beim Build-Prozess ausgeführt werden.

Trotzdem betrachte ich die Beziehung zwischen den Schichten als Einbahnstraße. Dem ViewModel ist es egal, was die Oberfläcge zur Anzeige bringt. Die Oberfläche kann aber nur das anzeigen, was vom ViewModel bereitgestellt wird. Wenn im ViewModel eine Aktion ausgeführt wird und diese Aktion keinen Zustand ändert, dann kann die Oberfläche auch nichts diesbezügliches darstellen, D.h., wenn der Model keine Zustandsangaben liefert und es keine Festlegungen zu Time-out gibt, dann kann die Oberfläche auch keinen Zustand "Fertig" darstellen.

--
Peter

Answer 16

Hi Scotty,

erst mal möchte ich hier Peter zustimmen. Ich sehe es genau so.

Dann  möchte ich anmerken das du ein Pattern (MVVM) zu sehr an eine Technologie (WPF) verknüpfst.

Pattern sind erst mal Technologie neutral, in den meisten Fällen gibt es Technologien, die die Pattern besser unterstützen und welchen, die die Pattern schlechter unterstützen.

Was die meisten Pattern gemeinsam haben, die sich um Darstellung Logik und Daten kümmern. Ist genau die 3 Aspekte sauber von einander zu trennen sind.

Und davon ist im Quellcode einfach die Logik, das Komplexeste was man Programmieren muss. Und der Punkt an dem man im Quellcode die meisten Fehler machen kann. Deshalb sollte man dafür auch Unit Test schreiben. (Die andern beiden Aspekt sind natürlich auch wichtig, aber über UI oder DB Designe hab ich in meinen Quellcode keinen wirklich großen Einfluss, ist die kurz Ausgae ich denke mal die Abhängigkeiten kennst du) .

Mit freundlichen Grüßen

Björn

Answer 17

Hallo Peter, hallo Björn,

vorab knüpfe ich das Pattern nicht grundsätzlich an WPF, mein Hardware Beispiel sollte das zeigen. Was die Einbahnstraße betrifft so sehe ich das als Datenfluss. Solange es nur eine Anzeige gibt mag das so sein. Doch sobald von der View oder dem Model Interaktionen stattfinden ist keineswegs mehr eine Einbahnstraße. Sicherlich in einer reiner Softwareanwendung kann man es so betrachten. Wenn man bspw. mit einem abgetrennten Dataset arbeitet wird dieses kaum seinen Zustand ändern. Ist die Datenquelle aber eine Hardware-Schnittstelle die Daten entgegen nimmt und auch Daten zurückliefert, kann es keine Kommunikation in eine Richtung sein.

Genau mit diesem Beispiel wären wir wieder beim Ausgangsthema "Wer sollte INotifyPropertyChanged implementieren?". Hier müsste also das Model die Schnittstelle implementieren. Wie sollte sonst das ViewModel mitbekommen dass das Model seinen Zustand geändert hat? Hier mal ein Beispiel:

Wie man sehen kann ist es eine Betrachtung. Für den PC ist die Hardware-Schnittstelle die Datenquelle(Model). Für die Schaltung hingegen ist die Hardware-Schnittstelle die View. Ich kann das Pattern also auf beiden Seiten ansetzen. Soll meine Kommunikation nicht mehr USB stattfinden, sondern über Netzwerk brauche ich nur das Model auf dem PC und die View in der Hardware tauschen. Der Rest bleibt unberührt. Gleiches gilt wenn ich aus der UI aus einer "normalen Anwendung" eine Webanwendungen machen will. Ich brauche nur die View(UI) auf dem PC austauschen, ohne irgendwelche Änderungen in dem ViewModels vorzunehmen. Selbst wenn die Maschine getauscht wird, weil sie stärkere Driver bekommen hat muss ich nur das Model der Hardware anpassen.

Zu beachten ist, das die UI mit der Maschine kommunizieren muss. Sprich über der UI mitgeteilt wird was die Maschine zu tun hat. Die Maschine hingegen der UI mitteilen muss was sie gerade tut. Ergo Peter, keine Einbahnstraße. Und Björn ich hoffe Du siehst dass ich das Pattern nicht automatisch mit WPF in Verbindung bringe.

Letztendlich gibt es wirklich getrennte Bereiche. Ich könnte einen Designer für die UI verpflichten, einen Software-Entwickler das ViewModel des PC, ein Software-Entwickler für das Model, einen Hardware-Entwickler für Hardware-Schnittstelle, einen Hardware-Entwickler für die Logik der HW usw. Niemand brauchte wissen wie der andere irgendetwas tut, wichtig ist lediglich das die Vereinbarungen(Schnittstellendefinition) eingehalten werden.

Gruß Scotty

Answer 18

Hi Scotty,

netter ansatz wobei es bei der View je eigendlich eher um die UI geht. deine ViewModel in der Hardware sollte ja die Daten schon so breitstellen das man sie nutzen kann. Da ist die View dann unnötiger Code.

Über den Datenzugriff macht das MVVM Pattern ja keine Aussage, man kann wie du es hier Vorgestellt hast den zugriff über das Model machen aber auch über das ViewModel, z.B. mit dem Reposetory Pattern und IOC. Wird auch hier im Buch so vorgestellt. Das ist ganz angenehem bei Unit Test, da man z.B. Datenbank zugriffe die das Reposetory macht, relativ einfach Mocken kann. Und so bei den Tests nicht mehr von der Datenbank abhängt.

MGF
Björn

Answer 19

Hallo Björn,

warst Du es nicht der gesagt hat es ist nur ein Muster und sollte nicht mit einer Technologie in Zusammenhang stehen?

Genau dieses Szenario habe ich beschrieben. Du schreibst aber jetzt, das die View das UI darstellt. Ebenfalls gehst Du von einem Datenzugriff aus. Genau das will ich damit aussagen- Es ist kein Zugriff sondern ein Austausch. Die Benachrichtigungen müssen also in beide Richtungen laufen. Bei einem Zugriff erfahre ich erst nach dem Zugriff ob sich etwas geändert hat. Bei einem Austausch werde ich informiert.

Verabschiede Dich mal von einer DB oder UI. Nenne es einfach Datenquelle/ -senke und Ein-/ Ausgabe. Schon hast Du ein abstraktes Muster ohne Technologiezuordnung.

Gruß Scotty

Answer 20

Hallo Scotty,

nun du hast den zusammen hang Technologie(WPF) und Muster (MVVM) genracht.

UI ist keine Technologie, es gibt viele Technologien mit der man die UI umsetzen kann. Und es gibt viele Muster (MVC, MVP, MVVM), die sich damit beschäftigen Daten (Model) mit der Logik (VM) so den User als Interface (UI (View)), bereit zustellen, das der damit Arbeiten kann.

Wenn es keine UI gibt, macht das Pattern wenig sinn.

Natürlich kann man auch im Hardware nahen bereich mit Schichten/Klassen arbeiten. Und wenn man sich mit einem Kollegen unterhält der das MVVM Pattern kennt aber nicht deine Aufteilung. Kann man auch sagen, hier die Hardware Interfaces das entspricht in etwa deinem View, hier die Circuit-Logic entspricht deinem ViewMode und die In-/Outputs entsprechen deinem Model.   

Das ist dann aber nicht das MVVM Pattern, bei MVVM ist die UI die View, bei der Hardware entspricht das Hardwareinterface der View, es ist aber nicht die View.

Mit freundlichen Grüßen

Björn

Answer 21

Hi Karsten,
wir reden aneinander vorbei.

Du betrachtest primär einen Informationsfluss; ich betrachte primär Objekte mit Zuständen und Methoden, die Zustände ändern können, und ggf. auch Ereignisse, die Zustandsänderungen mitteilen können. Und in meiner Betrachtungsweise ist es dem ViewModel völlig egal, wie die UI die Zustände des ViewModels für die Anzeige nutzt, welche Methoden die UI im ViewModel aufruft, und, welche Ereignusse die UI konsumiert. Lediglich die Spezifikation des ViewModels muss der UI-Designer kennen, da er nur das ansprechen kann, was im ViewModel vorhanden (implementiert) ist. Implementiert ist das, was in der Spezifikation (Pflichtenheft) vereinbart wurde. Wenn im ViewModel mehr Funktionalitäten realisiert sind, als sie im konkreten UI genutzt werden, ist das völlig bedeutungslos. Es gibt also nur eine Einbahnstraße vom ViewModel zum UI.

Wenn Du Dich aber von der objektorientierten Betrachtungsweise entfernst und Datenflüsse betrachtest, dann ist das natürlich keine Einbahnstraße. Nur nutzt Dir diese Betrachtungsweise nicht bei Tests, insbesondere bei automatischen Unit-Tests. Dort musst Du von einer vollständigen Kapselung ohne die Betrachtung angedockter Auf- und Abrufe ausgehen.

Auch ein "abgetrenntes DataSet" (was immer das auch sein mag), kann seinen Zustand (Daten) ändern. Das kann beispielsweise der Fall sein, wenn der Model, der für den Inhalt des DataSet verantwortlich ist, ein zeitgebergesteuertes Polling ausführt oder Remote-Ereignisse empfängt und verarbeitet (z.B. MSMQ). Diese Zustandsänderung ist dann irgendwie dem Nutzer des Models (z.B. ViewModel) anzuzeigen (z.B. mittels INotifyPropertyChanged oder indirekt über eine ObservableCollection anstelle eines DataSets). Ob und wie dieses Ereignis genutzt wird, ist dem Nutzer (z.B. ViewModel) völlig egal. Es ist aber testbar.

Dementsprechend kann auch eine Hardware betrachtet werden, wann man das MVVM Entwurfsmuster nutzt. Der Model verarbeitet die gesamte Verbindung zur Hardware. In Abhängigkeit vom Zustand der Hardware werden im Model Eingenschaftswerte gesetzt, unabhängig davon wer und wie diese Werte genutzt werden. Ggf. müssen für diese Vorgänge auch Zeitgeber eingesetzt werden, wenn sich die Hardware nicht automatisch mit Ereignissen meldet (z.B. Time-out). Zustandsänderungen im Model werden über INotifyPropertyChanged signalisert, egal, ob das jemand haben will und wie das dann z.B. im ViewModel genutzt wird. Für das Ändern von Zuständen des Models werden Methoden veröffentlicht. Wer die Methoden aufruft, ist dem Model völlig egal. In diesem Sinne ist das eine Einbahnstraße.

Ob es sinnvoll ist, das MVVM Entwurfsmuster auch auf die Hardware anzuwenden, kann ich nicht beurteilen. Ich kann es mir nicht vorstellen. Wenn es sich bei der Hardware aber um Firmware handelt, dann könnte man sich an MVVM anlehnen, vorausgesetzt, die Firmware Umgebung bietet die dafür benötigten Techniken.

--
Peter