Eine Listview verschiedene ViewModel WPF<-> MVVM - Teil/Frage2

Sali Community,

Ich hoffe ihr könnt mir weiterhelfen. in Bezug auf meinen Thread http://www.mycsharp.de/wbb2/thread.php?threadid=116621 .

Ich fange eigentlich erst richtig an (oder versuche es zumindest) MVVM zu verstehen (Versuche es 🙂 )

Ich habe versuche gerade folgendes: ( Ich verweise auf meine X( exzellente Zeichnung im Anhang - haha - aber ich hoffe das hilft )

Ich habe ein 2 Projekte: Einmal ein Core-Projekt mit meinen Core-Klassen und eine ViewProjekt mit meinen Views (Ist ja auch eigentlich egal und für mein Problem irrelevant).

So... ich habe Eine Basisklasse: Base von dem 3 Kinder erben. Klasse A / B / C. Nun habe ich noch eine weitere Klasse: Elementlist die aus einer Liste von Basisklasse besteht (um Objekte von A / B / C aufnehmen kann.). Hier sollen auch suchen nach Elemente implementiert werden etc nach A / B / C.

Soweit so gut. nun habe ich ein alle meine Views: ViewModel_1 ist gebunden an ein Objekt von Klasse A - ViewModel_2 an Objekt von Klasse B etc... Alle Views sind abgeleitet von ViewModelBase

So nun kommen ich langsam zu meinem Verständnis-Problem:

Ich habe nun eine View --> ViewModel_Elementliste (im großen und ganzen eine ListView im xaml) die möchte ich an Objekt von Klasse Elementlist hängen. Elementlist ist ja eine Liste von Klasse A / B oder C.

Muss ich nun in der ViewModel_Elementliste Objekte erzeugen von meinen Views (ViewModel_1 , ViewModel_2, etc) oder kann ich einfach Objekte der Klasse A / B oder C erzeugen ?

Es kann ja sein das ich eine Methode in implementieren muss die mir erst ein nach dem erzeugen eines Objektes A erst ein ViewModel_1 erzeugt und das wiederum zu einer Liste von ViewModelBase hinzufügen?

Was mir nicht klar ist. Ich würde Suchfunktionen im Core implementieren und NICHT in den ViewModels (oder ist das falsch vom MVVM-Ansatz?)

Was gehört nun in mein ViewModel_Elementliste? Erzeuge ich hier ein Objekt von meiner Klasse Elementlist oder eine Liste von ViewModelBase.
Für was bräuchte ich dann suchfunktionen im Core ? Wie füge ich elemente meiner Liste (Elementliste oder List<ViewModelBase>) hinzu ?

Ist das so verständlich ? Der TemplateSelektor der Implementiert ist muss dementsprechend ja auch angepasst werden. (Er funktioniert soweit).

Oh man ich hoffe ich konnte es gut genug erklären bzw. verständlich. Ich glaube das angehängte Bild sagt fast mehr aus.

Kann mir jemand (ich möchte es verstehen) sagen wie ich es zu implementieren habe also was RICHTIG ist?

Fettes merci im Voraus.

Ich stehe mit dem Viewmodel-Konzept bisserl auf Kriegsfuss.

Weil wenn du eine Viewmodel-Schicht zwischenschiebst, dann darf deine Anwendung in keinem Fall mehr jemals auf eine Model-Klasse zugreifen.

Mit dem Ergebnis, dass die Model-Klasse eiglich garnix mehr zu tun hat.

Wie dem auch sei: Wenn du das so aufziehen willst, merk dir einfach - das ist meine Antwort auf deine Frage: Deine Anwendung darf nur über Viewmodels agieren, nix anners.
Insbesondere Suchen und Löschen und Scherze - muss alles auf den Viewmodels laufen.

Ansonsten müsstest du ja ein mordsmäßiges Benachrichtigungs-System implementieren, und damit versuchen, dass das Viewmodel was empfängt vom Model, und darauf geeignet reagiert.
Das wird ziemlich kompliziert, und evtl. auch nicht immer lösbar, und v.a. wäre es von hinten durch die Brust ins Auge.

Edit:
Ich sehe grade, ja, du steckst mitten drin, und hast bereits doppelte Listen-Führung angefangen, es gibt bei dir Viewmodel-Listen und Element-Listen.
Ja, wird lustig. Wie gesagt: Die Anwendung agiert nur auf dem Viewmodel, und dass muss mw. iwelche Mechanismen haben, dass das Model ständig nachgeführt wird.

Wie gesagt: versuche nicht andersrum, das Viewmodel dem Model nachzuführen, oder gar Mixturen davon.

Hmmm, erstmal Danke, aber die Antwort (und das meine ich jetzt nicht böse oder sonst irgendwie negativ) ist nicht gerade befriedigend....

Was ich mit MVVM bisher mitbekommen habe (ja und ich weiß das man es anders machen kann) ist das man halt alles in kleine Views packt und das solange aufbaut von kleinen einzel Elementen bis zur kompletten View....

In Bezug auf "Die Models haben sonst nichts mehr zu tun"... ja da hänge ich auch noch ein wenig... Aber es muss so gehen sonst würde das komplette MVVM-Pattern KEINEN Sinn machen...

Etwas rundheraus abzulehnen, weil "Sonst würde etwas (anderes) keinen Sinn machen" - naja, das ist kein Begründen, sondern ist im Kern dogmatisches Denken. Also wo (bei Unvereinbarkeit) die Lehrsätze Vorrang haben vor dem, was sich aus Anschauung der Realitäts ergibt.
Prinzipiell sollte man sich aber imo den Kopf so weit freihalten, dass es tatsächlich auch vorkommen kann, dass etwas keinen Sinn macht - sowas gibts halt inne Realität.

Aber auch sonst ist das Argument ganz unlogisch:
Wieso macht MVVM keinen Sinn, nur weil sich in konkreten Einzelfällen oft genug zeigt, dass die Auftrennung von Viewmodel und Model unpraktikabel ist?
IMO tut das dem MVVM-Pattern garnix. Und es gibt weiterhin noch jede Menge Fälle, wo diese Auftrennung unverzichtbar ist.
In diesen Fällen kann man das begründen, und zwar besser als mit "sonst würde iwas anneres kein Sinn mehr machen".

Ansonsten -

...das man halt alles in kleine Views packt und das solange aufbaut von kleinen einzel Elementen bis zur kompletten View... Ja, seh ich auch so.
Und die Vorgehensweise gilt nicht nur für Views, sondern auch für Viewmodels, und wenn man auch ein Model hat, gilt es auch dafür.

Egal.
Solche Diskutiererei verwäscht nur den Kern, den ich dir mitteilte:

Aktionen deiner Anwendung dürfen ausschliesslich nur übers Viewmodel laufen.
Sobald du am Viewmodel vorbei iwas am Model rumfummelst, können inkonsistente Zustände entstehen, Scherze wie dass im Model etwas anders einsortiert ist als im Viewmodel usw...

Bitte fasse das auf, und probier, ob es als Richtschnur funktioniert.
Und probier gerne auch aus, es iwie anders zu machen, das wäre sogar ausgezeichnet, dann hast du eine Vergleichsmöglichkeit.

Noch toller wäre - allerdings quasi ein Rewrite - du probierst es ganz spasseshalber auch mal ohne Viewmodel/Model - Trennung - nur um zu sehen, wie weit du damit kommst, und ab wann der Ansatz sich dann tatsächlich als unzureichend erweisen wird.

Lieber ErfinderDesRades,

Ich sehe das Forum hier als Diskussionsgrundlage für ein Problem, für ein konkretes Problem, welches jemand hat (und in diesem Fall eines das ich habe). Ich habe von Dir nichts abgelehnt. Ich sehe aber keine neue Info die ich nicht schon habe... und ob Du auf dem Kriegsfuß mit MVVM stehst, kann und will ich nicht beurteilen und ist eine Meinung (Ja Deine, die Du natürlich haben kannst und was ich auch I.O. finde). Aber das bringt MICH nicht weiter (und nimm das bitte als konstruktive Kritik - also nicht böse gemeint). Und ob es Spaßig ist oder nicht mit Listen etc..... ??? Ja gut, bringt mir aber auch nichts und bringt mich meiner Lösung nicht weiter. Ich will etwas verstehen wieso und weshalb... Ich habe auch nichts abgelehnt ????

Bzgl. des "dogmatischen Denken"... Ich würde nicht nachfragen wenn ich so denken würde... Ich fragte nach einer Lösung oder besser Lösungsansatz oder noch besser ein Richtung..... Funktioniert es so im Sinne des Erfinders (MVVM - Pattern)

Aber es kommt mir gerade so vor das Du es ablehnst so etwas mittels MVVM-Pattern umzusetzen weil Du es nicht gut findest/oder magst oder vielleicht auch in diesem Fall nicht einsetzen würdest. (So liest es sich zumindest). Ich würde es gerne in MVVM umsetzen um es zu verstehen und ob es möglich ist und wenn ja wie... und wenn nein auch ok. Aber ich will eine Richtung. So wie ich jedem anderen zeigen würde wie es geht wenn ich es wüsste...

Aber egal ich will hier keine Diskussion dafür ist mir meine und auch Deine Zeit zu schade und bringt mich nicht näher an mein Ziel....

Ich habe schon WPF-Anwendungen geschrieben ohne das MVVM Pattern zu verwenden. Das ist nicht das Problem. Wirklich nicht... und wie in meiner Ausgangsfrage auch zu sehen ist verwende ich mehrere Views, als auch ViewModel....

Ja ich bekomme es hin das alles ohne ViewModel umzusetzen, aber vielleicht will ich das ja genau nicht weil:.... ich einfach mal (und glaub mir ich versuche mich an dem Projekt nur daran weil ich das Pattern für mich LERNEN will - und das Projekt einfach mal sauber gliedern will.

Wenn jemand hier sagt das IST der falsche Ansatz wie du das machst. Mach es "SO", denn SO macht es mehr sinn (mit ODER ohne MVVM) dann sehe ich es mir an ich bin dafür offen. Ich will ja was lernen. Ganz nach dem Spruch: Viele Wege führen nach Rom. Aber vielleicht will ich einfach mal eine "Landkarte" für das Ziel. Also etwas an dem ich mich entlang-hangeln kann.

Als Antwort auf meine Frage: "Mach nur alles in ViewModels... oder verwende es mal nicht" bringt mich nicht wirklich weiter.... Sorry

Es gibt ein paar Videos im Netzt in Bezug auf MVVM (mag da hingestellt sein ob es was mit meinem Problem zu tun hat oder nicht)... Aber es wir immer erst der Core mit seinen Models geschrieben und danach das VM, die auf das Model aufbauen. Und wenn ich es noch richtig weiß wird die meiste Logik in das Model gesteckt. Wenn ich jetzt aber in einer Liste suchen soll.... Hmm wieso soll dann diese Logik in das VM und wenn ich ein neues Element hinzufüge ?

ich find, du fasst überhaupt nicht auf, was ich sage.
Nirgends lehne ich den MVVM ab.

Auisserdem gebe ich dir doch auch eine Richtschnur, in genau deinem Sinne:

Aktionen deiner Anwendung dürfen ausschliesslich nur übers Viewmodel laufen.
Sobald du am Viewmodel vorbei iwas am Model rumfummelst, können inkonsistente Zustände entstehen, Scherze wie dass im Model etwas anders einsortiert ist als im Viewmodel usw... Wie kannst du das übersehen, wo ichs extra eingerahmt habe?
Diese Richtschnur macht ja überhaupt nur Sinn unter Vorraussetzung einer Trennung von Model und Viewmodel, also folgt ganz genau dem, was du bisher mit MVVM mitbekommen hast.

Aber ich kann auch weiter auf konkrete Einzelfragen eingehen - prinzipiellere Betrachtungen scheinen ja iwie problematisch. Also du frugst

Was gehört nun in mein ViewModel_Elementliste? Erzeuge ich hier ein Objekt von meiner Klasse Elementlist oder eine Liste von ViewModelBase.
Für was bräuchte ich dann suchfunktionen im Core ? Wie füge ich elemente meiner Liste (Elementliste oder List<ViewModelBase>) hinzu ? Ja, in ViewModel_Elementliste muss ein Objekt von Model_Elementliste enthalten sein.
Ob du es nun injizierst oder ob du es selbst erstellen lässt - Profis werden jetzt vermutlich mit einem DI-Framework kommen zum injizieren.
Ja, und eingefügt werden nur Viewmodel-Elemente - ganz getreu obiger Richtlinie. Das ViewModel_Elementliste muss dann einen eigenen Mechanismus haben, dementsprechend der (im ViewModel_Elementliste enthaltenen) Model_Elementliste auch was zuzufügen.
Mit entfernen dito, parallele Listenhaltung eben.

Auch hier ist wieder offen, wie du in die zugefügten Viewmodels die Models reinkriegst.
Jedenfalls wenn deine Viewmodel einen parameterlosen Konstruktor bereitstellen eröffnet dir das die Option, etwa in einem Datagrid in der ZufügeZeile einen Datensatz zuzufügen.
Wohlgemerkt - nur eine Option - oft ist nicht geraten, das auch zu nutzen, aber die Option zu kennen schadet wohl nicht.

Für was bräuchte ich dann suchfunktionen im Core ? ja, weiß ich auch nicht. IMO brauchst du eine Suchfunktion im Viewmodel (getreu obiger Richtschnur), und nicht im Core.

Das MVVM Pattern sorgt immer wieder für Gesprächsstoff 😃

Das liegt meiner Meinung daran, dass bei diesem abstrakten Entwurfsmuster die Begrifflichkeiten in der Praxies verschwimmen können und auch von dem einen oder anderen anders aufgefasst werden. Daher gibt es auch verschiedene praktische Umsetzungen des Patterns.

Ich halte mir deshalb immer vor Augen, dass das Ziele vom MVVM Pattern eine lose Kopplung der Komponenten ist. Als "glue" zwischen View und Model fungiert das ViewModel.

Was man jetzt alles in der View, im Model und im ViewModel macht hängt auch stark davon ab, was man machen will und wie das Projekt-Setup ausschaut.

Abgesehen davon, dass ich kein großer Freund von Models mit enthaltener Geschäftslogik bin, macht das bei großen Projekten auch überhaupt kein Sinn. Es hängt natürlich auch davon ab, welche Strategie man verfolgt. Wenn mein Ziel ist, möglichst viel Logik in den Backend zu verschieben halte ich meine Models möglichst einfach.

Models sollten deshalb nur die Daten definieren die der Benutzer in der View eingibt bzw. verändert. Darüber hinaus kann sie noch einfache Validierungslogik und primitive Funktionen enthalten. Alles andere gehört schon ins ViewModel.

Das ViewModel liegt direkt hinter der XAML View und organisiert die Daten ( der Models). Deshalb würde ich auch deine Suche ins ViewModel geben. Wenn du alles korrekt umgesetzt hast, solltes du weder im Model noch im ViewModel ein using haben welches auf einen UI Namespace zeigt. Einzige Ausnahme wäre der Dispatcher.

Es gibt ein paar Videos im Netzt in Bezug auf MVVM (mag da hingestellt sein ob es was mit meinem Problem zu tun hat oder nicht)... Aber es wir immer erst der Core mit seinen Models geschrieben und danach das VM, die auf das Model aufbauen. Und wenn ich es noch richtig weiß wird die meiste Logik in das Model gesteckt. Wenn ich jetzt aber in einer Liste suchen soll.... Hmm wieso soll dann diese Logik in das VM und wenn ich ein neues Element hinzufüge ?

Je nach Projekt kann man entweder zuerst mit der View oder dem Model anfangen. Aber so strikt würde ich da nicht vorgehen. Um die View zu testen brauchst du ja evtl. auch wieder das ViewModel 😃

Das mit der Logik im Model gefällt mir persönlich nicht, wie bereits oben erwähnt. Die Frage ist auch, welche Logik? Ist das Geschäftslogik oder die Validierungslogik innerhalb eines Models?

Die "Logik" würde ich schon alleine deshalb ins ViewModel geben, da es oft vorkommt, dass man für eine bestimmte Aktion mehrere unterschiedliche Models in einem bestimmten Zustand benötigt. Diesen Zustand kannst du nur über das ViewModel prüfen, da dieses Zugriff auf alle Model-Instanzen hat (Model-Instanz a kann nicht auf Model-Instanz b zugreifen)

Evtl. hilft dir auch dieses Beispiel weiter http://archiv.get-the-solution.net/index-blog-1-14-77-Filter-Data-mit-MVVM-(Filtering-ListView,-ListBox-mit-MVVM) ?

Das liegt meiner Meinung daran, dass bei diesem abstrakten Entwurfsmuster die Begrifflichkeiten in der Praxies verschwimmen können und auch von dem einen oder anderen anders aufgefasst werden können. Einspruch!
Also ich find die Begrifflichkeiten bei MVVM wohltuend klar, und da verschwimmt auch nix.
Wenn ich da an MVP oder MVC denke - das war ja vlt. ein herum-rudern!

Aber bei Model, View, Viewmodel kann man für jedes Stückerl Code zeigen und begründen, wo's hingehört, und warum.

Ansonsten sehe ich die Unterteilung exakt so, wie von dir beschrieben, also nix mit "kann jeder sehen, wie wolle".

Leider geht beim verlinkten Sample der Download-Link nicht, und die im Blog eingesprenkelten Code-Snippets und Bildle sind ja nur "Versprechungen", die dann der Download halten müsste.

Hmmm,

Also es gibt wunderbare Videos zum Thema MVVM https://www.youtube.com/watch?v=iX2hrsWsTT0

Hier wird komplett 4 Gewinnt als gutes Beispiel erklärt (ist auch eine ganz gute Reihe, aber entsprechend lang)... Finde ich mit das beste "Tutorial" was ich je gefunden habe.... Hier wird in den Models (nur als Beispiel für hier) ein "Spielstein in eine Spalte fallen gelassen" also als Methode... Sprich für mich ist das die Geschäftslogik und ist NICHT im VM implementiert. Verstehe ich jetzt was falsch ?

Ich war bisher der Meinung das wenn ich eine Liste in einem eigen Objekt speicher und diese Objekte der Liste manipuliere, egal auf welche Weise. Dann tue ich das alles im Model. Das VM hilft nur für die Anzeige. Sonst würde ja bald das Model keinen Sinn mehr machen.

Also war ich der Meinung ich erstelle mir ein Objekt das eine Liste von meinen Objekten enthält. Das ViewModel implementiert dieses "Listen-Objekt"

Ich habe nach den Videos MVVM als saubere Lösung angesehen... (Die meisten Beispiele kann man ja in der Pfeife rauchen da sie das Thema mit einer Klasse und einer Textbox versuchen abzuhandeln).... Leider kann ich das Beispiel nicht ohne weiteres auf mich anwenden (ich versuche mich ja nicht an dem Spiel).... Und leider wird auch nicht (ist ja auch schon speziell) auf meine Frage eingegangen - logisch.

Wohin kommen denn sonst Datenbankanfragen? Sollen die jetzt auch ins VM? Wohl eher nicht. Ich habe es so verstanden das das VM die "Geschäftslogik für die View ist" Also wie soll sich die View verhalten. Ganz nach dem Motto "Form follows Function" und Function wäre mein VM und Form mein xaml (Klingt komsich wegen WindowsForms).

Sehe ich das falsch?

Hmm - kann man irgendwo des Codes habhaftig werden?
Ich mag da jetzt nicht stundenlang utube gucken, und versuchen, seine Solution vom Bildschirm abzuschreiben.

Ich hab das jetzt auch nicht verfolgt, was er im Einzelnen macht, um "Spielstein in Spalte fallenzulassen".
Vom Modell her sollte das nichts weiter sein, als dass einer Spielstein-Auflistung (nämlich der Spalte) ein Spielstein hinzugefügt wird.
Im Minimal-Modell würde als Spielstein sogar ein einfacher Boolean reichen, für schwarz oder weiss.

Also nochmal: das Model eines Vier-Gewinnt-Spiels braucht nicht mehr zu sein als ein Array mit 4 List<bool>

Alles annere wäre Viewmodel.

Naja, so jetzt aus dem Bauch heraus.

Kann man sein Werk iwo downloaden?

Weiß ich nicht... finde seine Arbeit aber als sehr sehr gut weil er es eigentlich mega sauber erklärt, + den Code dazu... Weiß nicht, glaube ich nicht....
Da er das ganze mega professionell macht finde ich es Top.

Als Erklärung für mich warum die Funktionalität ins Model sollte --> was ist wenn verschiedene System benutzt werden nicht nur WPF. Evtl. eine andere Oberfläche, z.B. DirektX, Dann müsste ich ja die Logik für jedes System extra neu implementieren.

Die Logik eines Arrays von List<bool>?

(oder kurz List<bool>[4])

nein, da musst du auch nix re-implementieren, wenn du eine Winforms-Oberfläche, Konsole oder sonstwas drauf ausetzen willst.

List<bool>[4] - da steckt schon eine Menge Logik drinne, imo fast ausreichend, um ein 4-gewinnt zu modellieren.
Hinzu käme noch ein Toggle-bool der sagt, welcher Spieler dran ist, und dann noch Logik, die testet, ob einer gewonnen hat.

Hier, ich hab mal ein TicTacToe gebastelt - ist ja von 4-Gewinnt nicht soo verschieden:
https://www.vb-paradise.de/index.php/Thread/92049-TicTacToe/

Aber ist wieder son Fall, wo ich Model und Viewmodel zu trennen zu faul bin.
Also ein Model könnte man da heraus-seggregieren als ein bool?[9] - also 9 nullable booleans, die aussagen, ob und von wem eine Zelle gesetzt ist.

Aber bringt alles nicht viel zu deim ich finde wirklich kniffligen Problem:
Nämlich du hast Listen von Model-Klassen und Listen von Viewmodel-Klassen.
Und weil du das hast, musst du Sorge tragen, dass diese Listen auch wirklich konsistent bleiben.

Weder 4-Gewinnt noch TicTacToe haben diese Problematik.

Das liegt meiner Meinung daran, dass bei diesem abstrakten Entwurfsmuster die Begrifflichkeiten in der Praxies verschwimmen können und auch von dem einen oder anderen anders aufgefasst werden können.
Einspruch!
Also ich find die Begrifflichkeiten bei MVVM wohltuend klar, und da verschwimmt auch nix.

Ich denke BeZi hat hier ein sehr gutes Beispiel gebracht in welchem man eindeutig sieht, dass diese Begrifflichkeiten nicht immer eindeutig zuordenbar sind. Siehe dazu auch folgenden Absatz.

Beim genannten 4-Gewinnt Beispiel sind die ViewModels anders organisiert (siehe auch https://dl.dropboxusercontent.com/u/14810011/VierGewinnt.zip ) Eine View hat dort nicht zwingend ein ViewModel, sondern kann wiederum mehrere ViewModels enthalten.

<ContentControl Content="{Binding Path=SpielerViewModels[0]}" 
                        ContentTemplate="{StaticResource SpielerViewModelDataTemplate}"/>

        <ContentControl Grid.Column="1" Grid.Row="0" Content="{Binding Path=SpielbrettViewModel}" 
                        ContentTemplate="{StaticResource SpielerbrettViewModelDataTemplate}"
                        Margin="10 0"/>

        <ContentControl Grid.Column="2" Grid.Row="0" Content="{Binding Path=SpielerViewModels[1]}" 
                        ContentTemplate="{StaticResource SpielerViewModelDataTemplate}"/>

        <TextBlock Text="{Binding Gewinnertext}" />

Das SpielerViewModel enthält hier eine Property vom Typ Spieler und ein boolean ob dieser gerade am Zug ist. Den Code hätte man also genauso ins MainViewModel geben können. Bei größeren Projekten kann eine solche Aufteilungen extrem unübersichtlich werden. Hinzu kommt auch, dass ich z.B. aus dem SpielerViewModel nicht auf die Instanzen vom MainViewModel zugreifen kann (Ist bei der Validierung relevant). Ich würde solche Verschachtelungen von ViewModels vermeiden.

Bzgl. der Kontroverse bei den Begrifflichkeiten: Ist für ErfinderDesRades das SpielerViewModel noch ein ViewModel oder ist das bereits ein für das Frontend erstelltes Model?

Sprich für mich ist das die Geschäftslogik und ist NICHT im VM implementiert. Verstehe ich jetzt was falsch ?

Im Prinzip hat er das Model vom MVVM Pattern gar nicht erst gemacht. Das Core Projekt ist bei ihm das Business Model. Wenn wir bei MVVM von einem Model sprechen, dient dies vorwiegend zum Anzeigen oder Bearbeiten der Daten im Frontend Client. Das muss nicht zwingend das Business Model sein. Es kommt aber vor, dass man die Business Objects bis zum Frontend durchschleift. Hat natürlich seine Vor- und Nachteile.

Das VM hilft nur für die Anzeige. Sonst würde ja bald das Model keinen Sinn mehr machen.

Die VM ist das Bindeglied zwischen View und Models. Es stellt die Daten über die Models bereit. Du hast es zum Teil bereits auch selbst beantwortet

Ich habe es so verstanden das das VM die "Geschäftslogik für die View ist"

Wohin kommen denn sonst Datenbankanfragen?

Datenbank-, WCF-, WebApi- und sonstige Zugriffe werden meist in "Services" gekapselt und ausgelagert. Stichwort Repositories. Die ViewModels greifen auf diese Repositories zu und befüllen damit die Models.

Als Erklärung für mich warum die Funktionalität ins Model sollte --> was ist wenn verschiedene System benutzt werden nicht nur WPF. Evtl. eine andere Oberfläche, z.B. DirektX, Dann müsste ich ja die Logik für jedes System extra neu implementieren.

Ein gutes Argument dafür dass hier die BOs als Model "missbraucht" werden.

erstmal vielen dank für das hübsche 4-Gewinnt! 👍
Hast du das gemacht, oder ist das das vom Video?

Und natürlich melde ich gleich mal an, dass es mir unerhört oversized aussieht - also 38 Dateien aufzusetzen, um son popeliges 4-wins zu gestalten - wie gesagt: Ich wäre mit einer popeligen 2-D-Liste von Booleans eingestiegen, und ich glaub, so viel mehr wäre da garnicht hinzugekommen.

Dann bringst du mich mitte Begriffe tatsächlich ganz durcheinander.

Was ist ein Model, ein Business-Model, ein fürs Frontend-erstelltes Model?
Ein Business-Objekt - ist das ein Model oder ein Viewmodel?

erstmal vielen dank für das hübsche 4-Gewinnt! 😮
Hast du das gemacht, oder ist das das vom Video?

Nein, das ist von dem Prof. bzw Youtuber.

Was ist ein Model, ein Business-Model, ein fürs Frontend-erstelltes Model?
Ein Business-Objekt - ist das ein Model oder ein Viewmodel?

Ich betrachte das Business-Model komplett isoliert von der Frontend Anwendung. Vlt. ist so ersichtlicher:

Business-Objekt <-> WCF Service <-> Rep. mit WCF Client -> DTO <-> Model <-> ViewModel <-> View

oder so wie es im 4 Gewinnt ist:

Business-Objekt=Model <-> ViewModel <-> View

Vlt. ist so ersichtlicher:

Business-Objekt <-> WCF Service <-> Rep. mit WCF Client -> DTO <-> Model <-> ViewModel <-> View leider nein.
Von alle dies dolle Dinge sagen mir nur Model, ViewModel und View etwas.
Und warum du <-> dazwischen-setzst ist mir auch unklar.

Aber nochmal zum Zip: Wie kommt das in deine DropBox?
Oder ist das die Dropbox vom Prof?

Es wird viel einfacher wenn man sich mal anschaut was das MVVM Pattern "im großen Ganzen" ist.

[Artikel] Drei-Schichten-Architektur

Hier ist das ganze MVVM Pattern nur der Teil der in Präsentationsschicht steht.
Also das ViewModel und der View haben erstmal überhaupt nichts mit der Businesslogik usw zu tun.
MVVM ist nur die Sicht auf die Daten.
Und dementsprechend ist das ViewModel auch nur der Teil der Anwendung der notwendig ist die Ansicht zu treiben.

Hihi - das ist, was ich am MVVM so liebe: Er ist recht klar definiert.
Diese 3 - Schichten-Geschichte scheint mir (ähnlich wie MVC, MVP) auch annähernd so viele Auslegungen zuzulassen, wie es Programmierer gibt.
Aber meinetwegen - MVVM bewege sich halt nur in der Präsentations-Schicht.

Aber vlt. solltem man auch nochmal auf Bezis Frage zurückzukommen:

Kann ihm jemand sagen, was in die ElementListe gehört, und was in die ViewModel_Elementliste?
Und wie man es richtig implementiert?

Guten morgen und danke für die Beiträge.

Hier ist das ganze MVVM Pattern nur der Teil der in Präsentationsschicht steht.
Also das ViewModel und der View haben erstmal überhaupt nichts mit der Businesslogik usw zu tun.
MVVM ist nur die Sicht auf die Daten.
Und dementsprechend ist das ViewModel auch nur der Teil der Anwendung der notwendig ist die Ansicht zu treiben.

Also dann sieht es ja so aus als hätte ich es richtig verstanden... das MV ist für das verhalten der View verantwortlich und bildet abstrakt ein Model ab. (So wie ein Model auszusehen hat)

Bzgl. dem Beispiel des 4 Gewinnt: 1 finde ich es NICHT übertrieben wie es aufgebaut ist... Es wird einem sofort klar wenn man den Code wieder anschaut, 2 sind auch Unity-Tests enthalten.
und das wichtigste: ES IST ALS BEISPIEL zu verstehen.

Das gute an objektorientierter Programmierung ist ja die "Welt" zu vereinfachen und so abzubilden wie sie ist. Klar kann man 4 Gewinnt auch '"kleiner/kürzer" implementieren. Aber das ist nun mal nicht das vorgehen und nicht das Ziels der Videoreihe.
Ich kann auch 4 Räder nehmen, je 2 mit einer Achse verbinden, das ganze anschieben und sagen ich bin mobil und komme ans Ziel (naja zumindest auf einer Geraden). Jetzt mache ich mir mehr arbeit bei ne Lenkung ein, einen Motor und schon bin ich etwas flexibler. Ob es not tut muss jeder für sich entscheiden - ich denke schon (vor allem wen man es sauber erlernen will)

Naja egal jetzt.

Ich weiss nur ich bin meiner Lösung keinen Schritt weiter...

Wer sich die Videos angeschaut hat, sieht das er in das MainViewModel - 2 SpielerViewModels Packt, wieso packt er hier nicht eine Liste von Spielern rein ? Wenn ich doch im SpielerViewModel
auf einen Spieler zurückgreife wieso nicht dann im Spiel auf einer Liste zugreifen ?

Das scheint Absicht zu sein, weil er keine 2 parallelen Listen haben will.
Deshalb gibt es nur eine SpielerVM-Liste im Viewmodel, aber keine Spieler-Liste im Model.
Ob das "richtig" ist, lasse ich mal dahingestellt sein - scheinbar kann man das Realitäts-Faktum, dass es 2 Spieler gibt, im Model weglassen, im Viewmodel dann aber wieder nicht.

Jdfs. ist mir dieses Kernproblem der Model-Segregation im MVVM-Patterns schon öfter begegnet:
Ein Model braucht evtl. Listen von Sub-Models, um seine Realität richtig zu modellieren.
Und ein Viewmodel braucht Listen von Sub-Viewmodels, um das View richtig zu modellieren.
Da die Sub-Viewmodels Wrapper von Sub-Models sind, entsteht an diesem Punkt eine sehr problematische redundante Datenhaltung.

Wie gesagt: Für dein Problem der parallelen Listenhaltung gibt weder 4-Gewinnt noch TicTacToe wirklich was her, denn beide Spiele haben sowas garnet.
Bzw. nur in ganz starrer Form, also es gibt 2 Spieler und basta.
Und initial werden Plätze angelegt, aber während des Spielverlaufs passiert da ja nix.

Edit: Hihi - guckmal, was ich grad in Core fund:

   public class Spiel {
      private readonly Spielbrett _spielbrett;
      private readonly IReadOnlyList<Spieler> _spielerListe;

      public void StarteSpiel() {
         throw new NotImplementedException();
      }
   }

Also sieht mir aus, als habe er anfänglich durchaus daran gedacht, eine SpielerListe auch im Model zu führen, aber später wieder verworfen, und dann vergessen, die Spiel-Klasse zu löschen.

Business-Objekt <-> WCF Service <-> Rep. mit WCF Client -> DTO <-> Model <-> ViewModel <-> View
leider nein.

Damit wollte ich zeigen, was bereits FZelle geschrieben hat.

Hier ist das ganze MVVM Pattern nur der Teil der in Präsentationsschicht steht.
Also das ViewModel und der View haben erstmal überhaupt nichts mit der Businesslogik usw zu tun.

Das sieht man auch recht gut, da es "hierarchisch" unter dem "Model <-> ViewModel <-> View" liegt. Je nach Umfang des Projektes, hat man halt eine oder mehrere Schichten mehr/weniger.

Wie gesagt: Für dein Problem der parallelen Listenhaltung gibt weder 4-Gewinnt noch TicTacToe wirklich was her, denn beide Spiele benötigen sowas garnet.

Ja und gerade weil es das nicht gibt bei mir frage ich nach einem Lösungsansatz.

Was ich gerne mache ist angenommen ich erstelle eine Klasse User, dann implementiere ich auch eine eigene Klasse UserListe die eigentlich aus nichts anderem besteht als aus einer Liste von User --> List<User> und implementiere alle möglichen Methoden wie filtern/Daten abändern etc.

So und genau das habe ich auch in meinem Projekt... (nur halt nicht User sondern Elementlist --> Liste<Base> ) kann ja sein das das schon "übertrieben/falsch" ist. Finde ich aber logisch da alles sauber gekapselt ist (IMO).

So und ich bin davon ausgegagen das ich nun eine View für meine verschiedenen Baseelemente erstelle und dann eine eigene View für die Liste.

Oder besseres Beispiel:
Klasse Auto

Klasse Mercedes : Auto
Klasse BMW : Auto
Klasse Audi : Auto

Klasse Autoliste --> List<Auto> (inkl. Add, Remove, Search, Filter / etc.)

So und nun die ViewModel und Views
Klasse BaseViewModel (keine View)

Klasse Mercedes_ViewModel (greift auf Klasse Mercedes zu) -> View -> Bild von Mercedes
Klasse BMW_ViewModel (greift auf Klasse BMW zu) -> View -> Bild von Mercedes (ne Spaß BMW)
Klasse Audi_ViewModel (greift auf Klasse Audi zu) -> View -> Bild von Audi

Klasse Autoliste_ViewModel --> was mache ich hier ??? Autoliste oder List<BaseViewModel>

Mein Gedanke war ich setze auf Autoliste und der Templateselektor "regelt" den Rest. --> Sprich ich arbeite NUR mit Autoliste und nicht den VIEWS. Das funktioniert aber nicht da meine Views zwar angezeigt (Mercdes/BMW/AUDI) werden aber"leer" sind (Keine Infos).
Darum geht es mir. Und ob es so richtig ist weiß ich leider auch nicht.

Nur so war für mich bisher klar das die View unabhängig von dem Model angezeigt wird....
Ach ja für mich sind die Klasse Auto / Mercdes/BMW/Audi und Autoliste die Models

Klasse Autoliste_ViewModel --> was mache ich hier ??? Autoliste oder List<BaseViewModel> Natürlich letzteres.
Und im View dann DataTemplates einsetzen für die verschiedenen SpezialTypen - wenn diese denn überhaupt spezifische Templates benötigen.

Weil grundsätzlich sind Autos ja einander sehr ähnlich, da würde es reichen, auf einen bestimmten Hersteller zu verweisen, und damit wäre abgegessen, obs ein Mercedes ist oder BMW.

Sorry, aber der Begriff 'Model' (sowohl in MMVM als auch MVC oder MVP) stellt die "BusinessLogic" dar, d.h. dort gehört all die Funktionalität hin, welche unabhängig von der UI ist (d.h. z.B. identisch für ein GUI- oder Web-Projekt ist)!!!
Ein 'Model' ist nicht immer nur eine reine Datenklasse.
Gerade in Verbindung mit [Artikel] Drei-Schichten-Architektur stellt das 'Model' die Schnittstelle zu der untergeordneten Schicht "BusinessLogic" dar (ähnlich wie FZelle und mfe es auch geschrieben haben).

Und gerade bei größeren Projekten werden oft z.B. noch Service-Klassen im WPF-Projekt benutzt, welche dann die Schnittstelle zur "BusinessLogic" darstellen. Dort wird dann Funktionalität untergebracht, welche für mehrere ViewModels (und deren Views) gebraucht wird, z.B. wenn man mehrere Sichten auf dieselben Datenklassen hat.

Datenbankfunktionalität gehört natürlich noch mal komplett separat davon (d.h. Zugriff nur über Repository-Klassen o.ä.).

Und z.B. Suchfunktionalität würde ich immer so zentral wie möglich implementieren, damit sie nicht in jedem VM neu kodiert werden muß.

Ein Projekt sollte immer schön hierarchisch organisiert sein und mittels "loser Kopplung" sollte Wiederverwendbarkeit und Austauschbarkeit ermöglicht werden.

Wenn man nur ein Projekt für ein bestimmtes Themengebiet entwickelt, dann fällt es natürlich schwer, die Grenzen zwischen den verschiedenen Projektteilen zu definieren. Wenn man aber anfängt, verschiedene Projekttypen (z.B. Konsole, GUI, Web) zu entwickeln (und insbesondere in einem Team), dann sollte einem recht klar werden (evtl. mit mehreren Refactoringzyklen), was wo hin gehört.

@TH69 Gut also wenn das so ist wie ich vermute habe dann muss die "Logik" in meine Klasse: Autoliste (Suche/Hinzufügen etc). umd VM & View sind rein für die "Betrachtung" zuständig.... (gut "Filtern" könnte man evt. in das VM schieben da es ja "nur" eine "Subliste" ist, aber Hinzufügen, Entfernen etc. Eigentlich in das Model). Ich sehe VM mehr als --> Ich blende was aus oder ein etc...

@Erfinder des Rades: Das Beispiel mit dem Auto war ein vereinfachtes Beispiel..... um mein Projekt verständlicher rüberzubringen... 😉

Prima!

Dann ist ja alles geklärt 👍 🙂