spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »CeDoMain«

Ja, ich habe das MVVM-Pattern wie es beschrieben ist, implementiert. ... Allerdings habe ich nur eine Zweiteilung und keine Dreiteilung - das ViewModel in der "Mitte" fehlt bei mir. Ist das schlimm?

Leider wiederspricht der erste Satz dem Zweiten. Wenn du dich nur an das hältst was dir am besten gefällt, heißt das nicht, dass du dich an ein Pattern hältst. Allerdings ist das nicht schlimm im Sinne von
... es wird so nicht funktionieren ... es wird auch so funktionieren. Nur wirst du so keinen großen Benefit aus der Nutzung von WPF ziehen, da WPF Hand in Hand mit dem MVVM-Pattern entwickelt wurde und auch so genutzt werden sollte.

Zitat von »CeDoMain«

Ich versuche mal Licht ins Dunkel zu bringen: Die Eigenschaften meiner Klassen, die ich in WPF anzeigen möchte, habe ich jetzt mit "INotifyPropertyChanged-Logik" versehen. Die GUI enthält im Code-Behind eine ObservableCollection, mit mehreren Klassenobjekten. In XAML programmiere ich dann DataTemplates, die die Klassen anzeigen können, indem sie Steuerelemente mit {Binding Path=PropertyName} an meine Klasse binden. Dann binde ich ein ItemsControl an die ObservableCollection, dass mir die Klassen dann anzeigt. So habe ich MVVM verstanden!?

Das hat leider wenig mit MVVM zu tun. Wie schon von BlueCobold gesagt, du nutzt WPF schlicht wie WinForms mit INotifyPropertyChanged-Interface als Zusatz. Beim MVVM-Pattern geht es um
die Trennung der Oberflächenbeschreibung (View) von derBuisnesslogik (ViewModel + Models). In deinem Falle wäre deine Oberfläche die View (Window oder UserControls oder beides in Kombination),
deren DataContext-Properties die entsprechenden ViewModels zugewiesen bekommen.
Deine eigenen Klassen wiederum stellen die Models dar und werden in den ViewModels instanziert.

Zumindest sollte die Nutzung das INotifyPropertyChanged-Interface die ganze Sache übersichtlicher machen als wie schon vorgeschlagen, eine wahrscheinlich riesige Funktion zu schreiben,
in der alles auf den aktuellen Stand gebracht wird.

MFG

Ja das ViewModel dient als eine Art Kapselung zwischen deinen Datenmodellen und der View .... man kann es auch als Wrapper bezeichnen. Dein ViewModel enthält eine Instanz deiner Klassen
als privates Feld und gibt dieses über Properties an die Views weiter. Properties des DataContext einer View (also die Properties des zugehörigen ViewModels) kannst du ganz normal Binden, genauso
wie du das mit Properties machst die du im CodeBehind der Views erzeugst.

Daher musst du auch nix am DataTemplates ändern .... abgesehen davon dass du den DataType der DataTemplates halt auf deine eigenen Klassen setzen musst, aber ich nehme an das hast du eh schon.

MFG

Ja das ist soweit alles richtig, bis auf die Sache mit dem INotifyPropertyChanged implementieren. Die ObservableCollection ist
eine besondere Version der C# List<> welche selbst die Notwendigen Events triggert wenn sich etwas in ihr ändert (daher wohl observable).

Du bräuchtest also lediglich:



Wenn du diese ViewModel dann als DataContext einer View setzt, kann du in dieser View an die Source einer ListBox deine EffectCollection binden.

MFG

Zitat von »CeDoMain«

Müssen die Objekte, die die ObservableCollection enthält wirklich nicht INotifyPropertyChanged implementieren?

Nein müssen sie wirklich nicht, ist auch hier Doku entsprechend dokumentiert. Einfach bis zur Überschrift Hinweise runterscrollen.
Dort steht dann im dritten Abschnitt, dass die ObservableCollection bereits das INotifyPropertyChanged-Interface implementiert und daher selbstständig auf Änderungen von Obejekten in der Liste hinweist.

Zitat von »CeDoMain«

Mit View ist also keine Listbox, sondern das Fenster gemeint, wo die ListBox drin ist? Dann bekommt auch das Fenster mein ViewModel als DataContext?

Eine ListBox ist ein WPF-Control. Eine View ist normalerweise ein Window oder ein UserControl. Ich selbst nutze immer ein leeres Window in das ich UserControls setze, wobei jedes UserControl eine View darstellt.
Das Window selbsts stellt die höchste Instanz der GUI dar und enthält auch das ApplicationViewModel. Die UserControls sind meist logische zusammenhängender Bestandteile der GUI, wie zum Beispiel,
meherer Buttons oder eine Ansicht mit der eine bestimmter Datentype dargestellt wird (Bei dir zum beispiel EffectView um Effect-Objekte darzustellen und zu bearbeiten).

Da du ja schon DataTemplates erwähnt hast .... du kannst mittels DataTemplates auch festlegen das bestimmte DatenTypen mit einer bestimmten View dargestellt werden. Dies ist meiner Meinung nach eines
der nützlichsten Konstrukte in WPF. Da du so sehr einfach (10-20 Zeilen) eine komplett dynamische Oberfläche erzeugen kannst in der beliebige viele Objekte mit vordefinierten Aussehen dargestellt werden.

MFG

Zitat von »QuickAndDirty«

Zitat von »CeDoMain«

Müssen die Objekte, die die ObservableCollection enthält wirklich nicht INotifyPropertyChanged implementieren?

Nein müssen sie wirklich nicht, ist auch hier Doku entsprechend dokumentiert. Einfach bis zur Überschrift Hinweise runterscrollen.
Dort steht dann im dritten Abschnitt, dass die ObservableCollection bereits das INotifyPropertyChanged-Interface implementiert und daher selbstständig auf Änderungen von Obejekten in der Liste hinweist.

Die Antwort geht an der Frage vorbei. Die ObservableCollection implementiert bereits das Interface, wodurch Änderungen der Liste (Elemente hinzufügen, entfernen o. ä.) überwacht werden können. Damit aber Änderungen innerhalb der Objekte überwacht werden können, müssen diese ebenfalls das Interface implementieren. (Ein einmaliges Auslesen sollte davon nicht beeinflusst sein, sondern wirklich nur das auf Änderungen hin Überwachen.)