Du bist nicht angemeldet.
Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
spieleprogrammierer.de »
Spieleentwicklung und Programmierung »
C, C++, C#, Java und andere Programmiersprachen »
17.02.2016, 15:27
Dann müssen meine Models also auch INotifyPropertyChanged implementieren?Wenn Model B von Model A abhängig ist, dann wird im Setter von A die onPropertyChange Methode halt für beide aufgerufen.
Lass solche persönlichen Angriffe lieber bleiben, meine sind härter.
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
17.02.2016, 16:20
Dann hast Du das Konzept noch immer nicht verstanden. Modelle sind völlig unabhängig von ViewModels. Deine gesamte interne Logik sollte auch komplett ohne ViewModels oder Views funktionieren. Sie kennen sich also schon untereinander und agieren miteinander (wenn auch bitte niemals im Zyklus). Das dürfen und sollen sie auch ganz direkt machen.Also bringt es den Models doch rein garnichts, wenn sie sich gegenseitig kennen - sie benötigen für alles was sie mit dem anderen machen wollen das zugehörige ViewModel.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BlueCobold« (17.02.2016, 16:26)
17.02.2016, 18:53
Nein klar, das passiert auch nicht.(wenn auch bitte niemals im Zyklus)
Ok, das bekomme ich hin. Aber wie bitteschön wird dann die View geupdated? Ich zeige nämlich auch Werte an, die der User nur angucken kann - aber die werden laufend von den Models geändert. Muss mein Model dann INPC implementieren?Das dürfen und sollen sie auch ganz direkt machen
Das habe ich bisher auch so gemacht - soweit kommts noch, dass ich ständig meine Views anpassen muss.Andererseits soll es auch möglich sein die Struktur des Models ändern zu können, ohne bei jedem Bisschen die kompletten Views umbauen zu müssen.
Dieses Prinzip von MVVM habe ich verstanden! Lass solche persönlichen Angriffe lieber bleiben, meine sind härter.
17.02.2016, 22:16
Diese Prinzipien kenne ich schon - hast du gut zusammengefasst.Normal haben nur die ViewModels dieses Interface implementiert. Vom Ablauf her sieht das Ganze dann so aus
... sobald eine View ein ViewModel als DataContext zugewiesen bekommt, abbonniert die View automatisch das
PropertyChanged Event. Sobald dieses auslöst überprüft die View ob ein DataBindung zu der Variable vorliegt
(deshalb übergibst du den Namen der Property beim Auslösen des Events), wenn ja updatet die View den Wert
indem sie den Getter der entsprechenden Property aufruft.
Möchtest du das Werte nur angezeigt werden so hast du verschiedene Optionen. Entweder du nimmst gleich einen TextBlock,
da dieser gar nicht erst editiert werden kann oder du gibst beim Binding den Mode mit Mode=OneWay an. Was bedeutet
dass der Wert nur abgerufen werden kann, aber nicht editiert.
Die Set-Methode einfach auf privat setzen könnte auch gehen, ist aber sicher keine schöne Lösung und könnte zu unschönen
Bugs führen.
Mein Problem ist beim ViewModel und beim Model - mit der View komme ich klar. Ich versuche es nochmal mit einem Beispiel:geschrieben, dass die Models untereinander kommunizieren dürfen - das ist ja bei meinem Beispiel der Fall.Deine gesamte interne Logik sollte auch komplett ohne ViewModels oder Views funktionieren. Sie kennen sich also schon untereinander und agieren miteinander (wenn auch bitte niemals im Zyklus). Das dürfen und sollen sie auch ganz direkt machen.
Lass solche persönlichen Angriffe lieber bleiben, meine sind härter.
18.02.2016, 20:30
So mache ich das im Augenblick auch... meine Lampen hier leuchten auch schon schön.Also angenommen, du willst statt einer UI ein Interface für ein Gerät anbinden, dann muss deine Anwendungslogik genauso das Interface darüber informieren, wenn ein Effekt einen Wert verändert hat.
Demnach würdest du also bei Veränderung des Wertes im OutputPin ein Event auslösen, welches du in der Geräteschnittstelle abfangen und weiterverarbeiten kannst.
Jetzt hab ichs glaube verstanden wie das mit der Übermittlung funktioniert.Das EffektViewModel leitet die Daten an Effekt weiter. Dieser verändert was um OutputPin. OutputPin löst ein Event aus, dass sich ein Wert verändert hat. OutputPinViewModel registriert sich auf dieses Event und in dieser Methode löst du dann INotifyPropertyChanged auf die Property aus, welche du an ein UI-Element in deiner XAML gebunden hast.
Stimmt das so wie h_dev das beschreibt, BlueCobold und QuickAndDirty?... und kann verschiedene Models an die selbe View koppeln - nur die Property Namen im ViewModel müssen einheitlich sein. Verstehe!So kannst du dann im Prinzip alles über dein Modell legen, egal ob UI, Geräte-Interface oder was auch immer - es muss halt nur auf das Event von deinem Modell reagieren.
Das ist schlau von MVVM.Lass solche persönlichen Angriffe lieber bleiben, meine sind härter.
18.02.2016, 22:57
Stimmt das so wie h_dev das beschreibt, BlueCobold und QuickAndDirty?
Was mache ich mit all den Eigenschaften, die nur durch die GUI (nicht durch die Models) geändert werden? Werden die in Feldern im Model gespeichert und das ViewModel greift dann drauf zu und kapselt sie mit Properties?
Ich erzeuge nicht generell für jedes Model ein ViewModel, sondern nur, wenn ich das Model gerade in meiner GUI anzeigen möchte. Korrekt?
18.02.2016, 23:09
Ok, das merke ich mir schonmal. Eigenschaften (z.B. Name), die das Model selbst betreffen, müssen aber dann im Model gespeichert werden oder?Also du meinst damit Eigenschaften die lediglich die GUI braucht oder ? Die sind auch im ViewModel, aber nicht Teil eines Models.
Also zum Beispiel die Farbe eines Textes, welcher sich rot färbt wenn man einen nicht zulässigen Wert eingibt ... das wäre einfach eine Color-Property des ViewModel.
Super, so war das auch gemeint!Ich würde das eher von der anderen Seite betrachten. Du entscheidest dich in welchen Ansichten (Views) du was editierbar (oder auch nur anzeigen) machen möchtest, daraus
kannst du dann ableiten welche Models Teil des zugehörigen ViewModels sein müssen. Alle anderen Models müssen folglich auch nicht Teil eines ViewModels sein.
So nebenbei gucke ich mir jetzt auch mal Commands an - ich hab das vorher über "normale" Events (z.B. ButtonSave_Click) gemacht - das ist ein bisschen unflexibel. Lass solche persönlichen Angriffe lieber bleiben, meine sind härter.
18.02.2016, 23:47
Eigenschaften (z.B. Name), die das Model selbst betreffen, müssen aber dann im Model gespeichert werden oder?
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »QuickAndDirty« (19.02.2016, 00:01)
C, C++, C#, Java und andere Programmiersprachen »
Templates vs. Interface
(06.12.2009, 20:55)
C, C++, C#, Java und andere Programmiersprachen » [c++] Vererbung zur Laufzeit
(10.07.2008, 13:24)
Programmierung und Informatik » Logfile - buffer ('TCHAR [1024]' in 'char*')
(05.05.2006, 08:36)
03.05.2024, 21:10
Zum Seitenanfang
Dank des Fold-Tag ist dieser Post ...
