Benutzer mit den meisten Antworten
WPF MVVM Verständnis

Frage
-
Moin zusammen,
ich habe nun die ersten kleinen Anwendungen in WPF realisiert und auch das bevorzugte MVVM Pattern eingesetzt. Nun möchte ich mich an eine etwas komplexere Anwendung heranwagen und stoße auf Probleme.
1. Model-Klassen
- Fertigungsauftrag
- Eingang (IO-Controller)
- Logbuch2. ViewModel
- FertigungsauftragViewModel > Ruft jede Minute den aktuell angemeldeten Fertigungsauftrag (AuftragsNr, MaterialNr, Menge, etc.)
- FertigungsLinieViewModel > Beinhaltet eine Liste mit den Eingängen welche alle paar Millisekunden abgerufen werden
- LogbuchViewModel > Meldungen zum StörungslogbuchSoweit alles OKAY! Ich habe meine Usercontrolls aufgebaut, und diese auch an die jeweiligen ViewModels angebunden. Doch wie gehe ich am besten vor, wenn ich z.B. die Fertigungsauftragsnummer aus dem FertigungsauftragViewModel auch in die anderen ViewModels weiterreichen möchte? Baut man dann ein weiteres ViewModel um die vorhanden ViewModels? Mein Bauchgefühl sagt mir Nein! Oder sind DependencyProperty's das Schlagwort dazu?
Antworten
-
Hi,
günstig ist es, wenn je Prozess, den das Programm zu verarbeiten hat, eine ViewModel existiert. Falls dieser Prozess an mehreren Stellen anzuzeigen ist und Änderungen auch sofort sichtbar sein sollen, dann sollte nur eine Instanz des ViewModels erzeugt werden, die dann in unterschiedlichen Views genutzt wird. Wenn jedoch der ViewModel sich jedes Mal die Daten vom Model holen soll, dann kann jeder View eine eigen Instanz nutzen. Wenn ein View auf mehrere Prozesse zugreift, dann kann es erforderlich sein, dass ein View mehre ViewModels nutzt. Dasselbe betrifft die Models. Jeder Model sollte einen Prozess bedienen und auch nur die Daten verarbeiten, die zu diesem Prozess gehören. Das kann dazu führen, dass unterschiedliche Model sich bezüglich des Zugriffs auf externe Daten teilweise überlappen können.Anhand der Bezeichnungen Deiner ViewModels sehe ich keine Notwendigkeit der Weitergabe einer Fertigungsauftragsnummer. Die Frage ist, woher bekommt der FertigungsauftragViewModel den Identifikator für den aktuell angemeldeten Fertigungsauftrag. Der FertigungsauftragViewModel stellt die Information für einen Fertigungsauftrag bereit. Den Identifikator für den aktuell angemeldeten Fertigungsauftrag kann er über eine Bindung vom View bekommen, wo der Auftrag ausgewählt wird. Der FertigungsauftragViewModel sollte entsprechend der Prozess-Herangehensweise alles zur Verwaltung eines Fertigungsauftrages beinhalten, z.B. Liste von Aufträgen, Hinzufügen eines neuen Auftrages, Ändern (des Status), Speichern, View über Änderungen informieren.
Eine DependyProperty benötigst Du nur dann, wenn du diese Eigenschaft für Bindungen brauchst. Aus Deiner Schilderung sehe ich da erst einmal keine Notwendigkeit.
--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks- Als Antwort markiert David Stania Freitag, 4. September 2015 09:43
-
Hi,
Deine Herangehensweise scheint mir nicht optimal zu sein aus der Sicht der Wartung und Fehlersuche im Code, wegen unzureichender Abgrenzung der Prozesse.Im ViewModel einen Zeitgeber zu haben, finde ich nicht gut. Da werden die Testmethoden recht komplex und die Wahrscheinlichkeit von unzureichenden und fehlerhaften Tests steigt. Da sich die Daten in der externen Datenquelle ändern, sollte der Zeitgeber auch im Model sein. Der Model meldet dann 1 Mal pro Minute den aktuellen Auftrag an den ViewModel.
Im ViewModel überlappen sich keine Daten, wenn es mehrere Instanzen gibt. Die Daten werden vom Model geliefert und es muss schon gewichtige Gründe geben, wenn Du die Daten nochmals im ViewModel hälst (koipierst) oder den Model nur als Zwischenschicht mit offenen Schleifen (yield) nutzt. Tests werden dadurch verkompliziert. Für jeden Prozess hast Du eine eigenen Datenpuffer, in welchem sich Daten überlappen können. Alles nur in einer eierlegenden Wollmilchsau zu konzentrieren, führt schnell zu Ressourcenproblemen und einer Verlangsamung der Arbeitsweise.
Was Du unter HauptView und direkte Bindung an die Steuerelemente verstehst, kann ich mir nicht vorstellen. Wenn Du mit UserControls arbeitest, solltes jedes UserControl seine eigene Instanz eines ViewModels haben. Ob das ViewModel dann völlig selbständig oder mit Hilfe eines singleton Models arbeitet, ist ggf. zu entscheiden.
--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks
- Bearbeitet Peter Fleischer Freitag, 4. September 2015 09:29
- Als Antwort markiert David Stania Freitag, 4. September 2015 09:43
Alle Antworten
-
Hi,
günstig ist es, wenn je Prozess, den das Programm zu verarbeiten hat, eine ViewModel existiert. Falls dieser Prozess an mehreren Stellen anzuzeigen ist und Änderungen auch sofort sichtbar sein sollen, dann sollte nur eine Instanz des ViewModels erzeugt werden, die dann in unterschiedlichen Views genutzt wird. Wenn jedoch der ViewModel sich jedes Mal die Daten vom Model holen soll, dann kann jeder View eine eigen Instanz nutzen. Wenn ein View auf mehrere Prozesse zugreift, dann kann es erforderlich sein, dass ein View mehre ViewModels nutzt. Dasselbe betrifft die Models. Jeder Model sollte einen Prozess bedienen und auch nur die Daten verarbeiten, die zu diesem Prozess gehören. Das kann dazu führen, dass unterschiedliche Model sich bezüglich des Zugriffs auf externe Daten teilweise überlappen können.Anhand der Bezeichnungen Deiner ViewModels sehe ich keine Notwendigkeit der Weitergabe einer Fertigungsauftragsnummer. Die Frage ist, woher bekommt der FertigungsauftragViewModel den Identifikator für den aktuell angemeldeten Fertigungsauftrag. Der FertigungsauftragViewModel stellt die Information für einen Fertigungsauftrag bereit. Den Identifikator für den aktuell angemeldeten Fertigungsauftrag kann er über eine Bindung vom View bekommen, wo der Auftrag ausgewählt wird. Der FertigungsauftragViewModel sollte entsprechend der Prozess-Herangehensweise alles zur Verwaltung eines Fertigungsauftrages beinhalten, z.B. Liste von Aufträgen, Hinzufügen eines neuen Auftrages, Ändern (des Status), Speichern, View über Änderungen informieren.
Eine DependyProperty benötigst Du nur dann, wenn du diese Eigenschaft für Bindungen brauchst. Aus Deiner Schilderung sehe ich da erst einmal keine Notwendigkeit.
--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks- Als Antwort markiert David Stania Freitag, 4. September 2015 09:43
-
Hallo Peter,
danke für die schnelle Rückmeldung!
Im FertigungsauftragViewModel ist ein Timer vorhanden welcher 1 mal pro Minute die Daten aus SAP abruft. Anhand der letzten Buchung kann ich dann sehen, welcher Auftrag aktuell angemeldet ist.
Mehrere Instanzen des FertigungsauftragViewModels möchte ich ungern machen, weil sich - wie du schon beschrieben hast - die Daten überlappen könnten. Daher suche ich nach einer Lösung, Daten von nur einer Quelle abzurufen.
Also wäre eine Möglichkeit im HauptView eine Instanz der FertigungsauftragViewModels anzulegen und in den jeweiligen UserControls die Information direkt an die Steuerlemente (Textbox) zu binden?
-
Hi,
Deine Herangehensweise scheint mir nicht optimal zu sein aus der Sicht der Wartung und Fehlersuche im Code, wegen unzureichender Abgrenzung der Prozesse.Im ViewModel einen Zeitgeber zu haben, finde ich nicht gut. Da werden die Testmethoden recht komplex und die Wahrscheinlichkeit von unzureichenden und fehlerhaften Tests steigt. Da sich die Daten in der externen Datenquelle ändern, sollte der Zeitgeber auch im Model sein. Der Model meldet dann 1 Mal pro Minute den aktuellen Auftrag an den ViewModel.
Im ViewModel überlappen sich keine Daten, wenn es mehrere Instanzen gibt. Die Daten werden vom Model geliefert und es muss schon gewichtige Gründe geben, wenn Du die Daten nochmals im ViewModel hälst (koipierst) oder den Model nur als Zwischenschicht mit offenen Schleifen (yield) nutzt. Tests werden dadurch verkompliziert. Für jeden Prozess hast Du eine eigenen Datenpuffer, in welchem sich Daten überlappen können. Alles nur in einer eierlegenden Wollmilchsau zu konzentrieren, führt schnell zu Ressourcenproblemen und einer Verlangsamung der Arbeitsweise.
Was Du unter HauptView und direkte Bindung an die Steuerelemente verstehst, kann ich mir nicht vorstellen. Wenn Du mit UserControls arbeitest, solltes jedes UserControl seine eigene Instanz eines ViewModels haben. Ob das ViewModel dann völlig selbständig oder mit Hilfe eines singleton Models arbeitet, ist ggf. zu entscheiden.
--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks
- Bearbeitet Peter Fleischer Freitag, 4. September 2015 09:29
- Als Antwort markiert David Stania Freitag, 4. September 2015 09:43
-
Hi,
Deine Probleme scheinen weniger das MVVM zu sein als vielmehr die funktionelle Strukturierung eines Projektes. Meine Gedanken zu MVVM findest Du hier.--
Viele Grüsse
Peter Fleischer (MVP, Partner)
Meine Homepage mit Tipps und Tricks