Laden...

Wieso Model, wenn man das ViewModel nutzen kann?

Erstellt von Exis vor 9 Jahren Letzter Beitrag vor 7 Jahren 16.126 Views
E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren
Wieso Model, wenn man das ViewModel nutzen kann?

Hallo,

ich versuche mich intensiver ins MVVM einzuarbeiten, jedoch habe ich immer beim Konzept das problem, dass wenn ich Model erstelle, ich nicht ganz weiß wie ich das in dem ViewModel nutzen soll. Also Beispiel, ich habe ein Model Person und ein ViewModel für Person. Aber ich könnte doch die Methoden im Model einfach ins ViewModel packen?

Ich finde immer nur so Ansätze im Internet wie: "Wir erstellen dies, erstellen das und fertig". Aber richtig was mit Erklärung finde ich nicht, geschweige den in Deutsch. Ich kann auch schön sagen ne While-Schleife geht so.. aber bringt ja nichts wenn ich diese nicht erkläre...

Also zurück zum ViewModel, das ViewModel erbt von meiner BaseViewModel, in welcher ich die OnPropertyChange Methode habe. Aber wie Kommuniziert nun das ViewModel Person mit dem Model Person. Z. b. stumpfes Beispiel. Die Person hat die Methode "Essen()". Diese könnte ich nun auch einfach ins ViewModel packen.. oder nicht?

Gruß.

74 Beiträge seit 2014
vor 9 Jahren

Hallo,

der Zweck des ViewModels ergibt sich wenn du verstehst was der Name sagt: "View Model". Bedeutet, es ist ein abstraktes Modell der Ansicht. Das heißt du hast nicht unbedingt eine ViewModel-Klasse pro Model-Klasse sondern jeweils eine ViewModel-Klasse pro Teil der Ansicht. Also für jeden Dialog, jedes Fenster usw.

Lies dir dazu diesen Artikel durch. Für den Einstieg finde ich den sehr gut.

Es wird dir wahrscheinlich klarer werden wenn deine Programmlogik aus mehr besteht als aus schulbuchmäßigen Beispielen à la "Person.Essen()" oder "Auto.Fahren()" 😉

Grüße

F
10.010 Beiträge seit 2004
vor 9 Jahren

MVVM ist ein Ansatz, der es in mehrschichtigen Anwendungen erlaubt die "Seperation of Concern" besser aufzuteilen.

Model ist hierbei das kleinste Element das durch alle Ebenen durch muss, und implementiert das dann auch nur.

Also wenn du eine Desktop App erstellst, mit ner "kleinen" Datenbank, dann wären die Poco die dir dein ORMapper befüllt das Model.
Diese haben dann genau so viel Businesslogic, wie nötig ist, also z.b. rudimentäre Validierung, Logging, was auch immer.

Die VM's sind dann dazu da diese Poco's an die Ui zu binden, und die UI Logik zu beinhalten.

Also noch mal knapp:
Model beinhaltet alles was wirklich im Domainobject gemacht werden muss, was also immer benötigt wird wenn man das Model benutzt.
Das ViewModel beinhaltet die Logik für den View, nicht mehr und nicht weniger.

2.207 Beiträge seit 2011
vor 9 Jahren

Hallo Exis,

ich schliesse mich meinen Vorrednern an. das ViewModel ist eine abstrakte Sicht deiner View.

Deswegen macht man auch gerne Interfaces von Viewmodels, obwohl WPF direkt auf die Implementierung bindet: Weil man gern eine "Zusammenfassung" der View hat.

Stell dir vor du musst etwas berechnen aus den Daten deiner Models. Das im UI zu machen, gerade im "kryptischen" XAML kann mühsam sein. Ergo machst du ein Property auf deinem ViewModel was dir das Ergebnis deiner Berechnungen darstellt. Davon abhängig verhält sich deine View entsprechend.

Gruss

Coffeebean

A
764 Beiträge seit 2007
vor 9 Jahren

Hallo Exis,

Hier der Link von oben nochmal in deutsch: https://msdn.microsoft.com/de-de/magazine/dd419663.aspx

Es ist eigendlich alles schon gesagt worden. Wenn du mal ein komplexeres Projekt hast, erklärt sich MVVM quasi von selbst.
Bei so kleinen Projekten kann man MVVM auch mal MVVM sein lassen. Genau das, was deine Frage aufgeworfen hat.

Gruß, Alf

P
1.090 Beiträge seit 2011
vor 9 Jahren

Hallo Exis,

wenn du es besser Verstehen möchtest kann ich dir das Buch Entwurfsmuster von der GoF empfehlen. Es behandelt zwar nicht das MVVM Pattern, erklärt aber sehr gut wozu Entwurfsmuster gut sind und stellt eine ganze Reihe von ihnen ausführlich vor. Grundlegend Sätzen Prinzipien wie SOLID, DRY und KISS um.

Wie die andern ja schon erwähnt haben kann man das Model auch direkt an die View binden. Das beschreibt John Grossman aber in seinen orginal Artikel auch so [1]

MFG
Björn

[1] MSDN(John Grossman):Introduction to Model/View/ViewModel pattern for building WPF apps

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Hallo und danke für die ganzen Rückmeldungen 😃

Hier der Link von oben nochmal in deutsch:
>

Genau das habe ich gelesen, unter anderem. Aber genau das verwirrt mich am meisten.
Wenn ich jetzt als Beispiel ein UserControl habe was mir eine Garage anzeigt.
Dann habe ich z. B. ein vmCarPark und ein vmCar.
In der vmCarPark erstelle ich eine assoziation zu vmCar. Das UserControl bekommt dann ein DataContext zu der vmCarPark und darüber greife ich dann auch auf die vmCars zu welche z. B. in einer Liste dargestellt werden. Nun habe ich aber eine ModelCarPark und eine ModelCar klasse.

Nun wie binde ich das ModelCar oder ModelCarPark zu seinem Model? Als Idee würde ich einfach im Konstruktor von vmCars das ModelCar übergeben. Aber dann kann ich doch auch das ModelCar weglassen und direkt nur ein vmCars haben.

Das irritiert mich richtig...

Gruß.

P
1.090 Beiträge seit 2011
vor 9 Jahren

Hallo Exis,

du schmeißt hier ein bisschen die Anforderungen durcheinander. Ob ich jetzt ein Model direkt an die View binde oder wie 2 VMs miteinander Daten austauschen, sind grundlegend 2 verschiedene Sachen.

Die beiden VMs sollten sich erst mal am besten nicht kennen. Dazu wie 2 VMs miteinander kommunizieren können, findest du viele Beispiele bei Google.

Um ein Model zu erzeugen gibt es auch X Weg, die einfach von der Anforderung abhängen. z.B. im Zusammenhang mit einer Datenbank ist das Repository Pattern einer der gläufigsten. Welches dann im VM verwendet wird.

Ließ dir mal die Dokumentation für Prism[1] durch. Dort solltest du eigendlich für jedes grundlegende Senario eine Beispiel (Pattern) finden wie man es umsetzen kann. Was jetzt nicht heißen soll das du das Prism Framework verwenden sollst, sondern schauen sollst wie dort die Probleme gelöst wurden.

MFG
Björn

[1]MSDN:Developer's Guide to Microsoft Prism Library 5.0 for WPF

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

5.299 Beiträge seit 2008
vor 9 Jahren

ich bin ja immer für einfache Lösungen.

Als Idee würde ich einfach im Konstruktor von vmCars das ModelCar übergeben. Aber dann kann ich doch auch das ModelCar weglassen und direkt nur ein vmCars haben.

Das irritiert mich richtig... Finde ich gut, wenn dich etwas irritiert, weils dir umständlich vorkommt.
Das ist oft nämlich ein Zeichen dafür, dass der Pattern nicht gut passt.
In kleinen Szenarien oder iwelchen Übungen mit Garagen und Autos macht der vollentwickelte MVVM-Pattern nämlich nicht wirklich sinn, und es ist wirklich sinniger, Model und ViewModel zusammenzuschmeißen.
Imo kann man anspruchsvolle Pattern nicht mit an Haaren herbeigezogenen Primitiv-Beispielen lernen.
Lieber sollte man einfach proggen, solange es einfach ist, und wenn die Anforderungen wirklich komplex werden - etwa das echte Geschäftslogik hinzutritt - erst dann sollte man die Concerns trennen, und Model und Viewmodel auseinanderdividieren.
Nicht Concerns aufteilen, wo noch gar keine Concerns da sind - das muss ja irritieren (jdfs. jeden, der noch einfach mit gesundem Menschenverstand denkt).

Der frühe Apfel fängt den Wurm.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Ok, also werde ich erstmal bei meinen kleineren Sachen die ViewModel quälen hehe.
Danke euch.

Ich habe in meiner MainView, habe ich viele UserControls welchen ich Listen per DataContext übergebe. Jedoch mache ich das immer so:

ItemsSource="{Binding LISTENNAME, RelativeSource={RelativeSource AncestorType={x:Type Window}}}"

Das klingt irgendwie nur halb richtig, es funktioniert zwar aber ich weiß nicht so recht...

Gruß.

5.299 Beiträge seit 2008
vor 9 Jahren

Aber du hast doch schon mein BeispielProjekt mitte Rectangles.
Da ist doch vorgeturnt, wie man an Viewmodels bindet.

Ein RelativeSource-Binding ist ja kein Binding ans Viewmodel, sondern da wird ja an annere Controls gebunden - das braucht man gelegentlich, um Daten-unabhängige Zustände der Oberfläche miteinander kommunizieren zu lassen.
Aber in deim Fall hat das Window offenbar eine LISTENNAME-Property, und das verstößt gegen MVVM, denn ein Window ist View (Oberfläche), und kein Viewmodel (Daten).

Du hast scheints dem Window iwas ins Codebehind reingeproggt, was da nicht reingehört.
Tatsächlich gehört so gut wie garnix ins Codebehind, der MVVM-Pattern ist so mächtig, dass im Normalfall komplett drauf verzichtet werden kann, iwas im CodeBehind zu coden.

Der frühe Apfel fängt den Wurm.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Ich mache im CodeBehind nichts.
Allerdings fummel ich alles gerade auch noch in die xaml cs datei.
Ich bin gerade dabei eine MainViewModel zu machen. Diese erstelle ich dann und mache in die MainWindow.xaml den DataContext auf das MainViewModel?

Zumindestens ist das das einzige was ich so rauslese aus dem RectangleTree. Mich verwirrt das irgendwie, woher der die Informationen halt nimmt manchmal.

Gruß.

//edit, ah so funktioniert es dann. So langsam komm ich richtig rein. Jetzt muss ich morgen damit anfangen alles vernünftig zu strukturieren, wo was hin kommt.

5.299 Beiträge seit 2008
vor 9 Jahren

Die Xaml.cs ist der CodeBehind. Da sollteste nichts reinschreiben!

Ich hab dir doch erklärt, wo der die Infos nimmt: Alles Xaml kann man per StaticResource-Binding an die einzige MainViewmodel-Instanz binden, die im App.Xaml angelegt ist.

Guck nochmal in den Code.

Vermutlich fehlen dir ein paar Grundlagen zur Xaml-Syntax:
Also ein einfacher Xml-Tag ist im Xaml das Instanzieren eines Objekts - also Konstruktor-Aufruf und pipapo.
Und so ein einfacher Xml-Tag steht inne App.Xaml - Resourcen, und damit ist das MainViewmodel instanziert, und steht damit allen Windows, und prinzipiell auch allen UserControls zum Anbinden zur Verfügung.

Nur bindet man UserControls meist an lokale DataContexte, denn die sind ja meist eingebettet in ItemsControls oder sowas.
Guck auch mal https://www.vb-paradise.de/index.php/Thread/83442-MVVM-Binding-Picking-im-Xaml-Editor/
Da kriegt man hofflich auch so einiges mit von dem wie Wpf tickt.

Der frühe Apfel fängt den Wurm.

V
3 Beiträge seit 2015
vor 9 Jahren

Ich mache im CodeBehind nichts.
Allerdings fummel ich alles gerade auch noch in die xaml cs datei.
Ich bin gerade dabei eine MainViewModel zu machen. Diese erstelle ich dann und mache in die MainWindow.xaml den DataContext auf das MainViewModel?

Zumindestens ist das das einzige was ich so rauslese aus dem RectangleTree. Mich verwirrt das irgendwie, woher der die Informationen halt nimmt manchmal.

Gruß.

//edit, ah so funktioniert es dann. So langsam komm ich richtig rein. Jetzt muss ich morgen damit anfangen alles vernünftig zu strukturieren, wo was hin kommt.

Die VM's sind dann dazu da diese Poco's an die Ui zu binden, und die UI Logik zu beinhalten.

Hinweis von Coffeebean vor 9 Jahren

Werbung entfernt. Community-Regeln

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Nochmal zu dem Thema eine frage.
Wenn ich jetzt ein ParkModel habe, welches ein Array von CarModels beinhaltet. Wie löse ich das im MVVM denn am besten? Erstelle ich ein ParkViewModel und übergebe in dem das ParkModel und im Konstruktor vom ParkViewModel erstelle ich die CarViewModel und übergebe denen die CarModels?
Was anderes fällt mir irgendwie nicht ein, zumindestens was ich für halbwegs logisch empfinde.

5.299 Beiträge seit 2008
vor 9 Jahren

Ja, das sind die Probleme, die aufttreten, wenn man Viewmodel und Model sauber auseinanderdividieren will.

Wenn du nämlich mehrere CarParks hast, und jeder CarPark hat mehrere Cars, dann brauchst du - nach Sauber-MVVM - mehrere CarParkVMs, und jedes CarParkVM enthält mehrere CarVMs, und jedes CarVM enthält ein Car.
Aber jedes CarParkVM enthält auch ein CarPark, und jeder CarPark enthält auch mehrere Cars.

Da hast du also ein sehr verworrenes Dickicht an miteinander in Beziehung stehenden Listen.
Jedes Car wird nun redundant in 2 verschiedenen Listen geführt:
Es ist (Model) in einer CarPark-Car-Liste drin, aber es ist auch ihn einem CarVM (Viewmodel) drinne, welches ja selbst wiederum in einer CarParkVM-CarVM-Liste drin ist.

Und beim Zufügen eines Cars muss das CarParkVM das Car sowohl im CarPark zufügen, als auch ein CarVM bilden, und dieses CarVM sichselbst zufügen.

Und zB. Löschen geht ja vom CarVM aus, und muss dementsprechend doppelt ausgeführt werden. Und wenn der User ein ganzes CarParkVM löscht - da muss iwie auch die Daten-Liste (Model) zugegriffen werden, denn nur das CarParkVM löschen greift zu kurz, wenn da noch iwo ein CarPark (Model) herumfährt.

Klar soweit?

Aber vlt. fehlt mir da auch KnowHow, und mit IOC-Containern oder sowas würde man das in den Griff kriegen.
Also würde mich auch interessieren, eine plausible Antwort auf diese Problematik zu erhalten.

Der frühe Apfel fängt den Wurm.

F
10.010 Beiträge seit 2004
vor 9 Jahren

IOC-Container haben da wirklich nichts mit zu tun.

Statt sich das Muster immer schlechter zu reden als es ist, sollte man sich mal einach vor augen führen warum es entstanden ist, und weshalb es deshalb so sinn macht.

MVVM ist als eines der vielen Kinder von MVC entstanden, also um Businesslogik von Datenhaltung und View zu trennen.
Man hat bei WPF gesehen, das mit einem mal der Entwickler und der Designer gemeinsam an einem Problem arbeiten können.
Also hat der Entwickler dem Designer eine "einfache" Sicht auf die Daten gegeben, die genau für den Businesscase gemacht wurde.
So kann z.b. der Designer zwar auf die Properties des Cars zugreifen, aber z.b. nur lesend.
In einem anderen Fenster muss man jetzt aber schreibend zugreifen.
Früher hat man dann eben dem Designer gesagt, hier darfst du nicht zugreifen, aber man hat es schwer verhindern können.
Jetzt bekommt er eben nur das was er darf.

Dadurch lässt sich vieles einfacher lösen, was aber nicht bedeutet das es weniger arbeit ist.
Ganz im Gegenteil.
Aber so lässt sich Software deutlich fehlerfreier erstellen.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

An sich halt richtig mit dem doppelten Listen. Aber ich verbinde die ViewModel zum Model mit einer Komposition, somit habe ich halt den Vorteil, dass ich nur das VM löschen muss und das Model wird ja mit gelöscht... aber ist schon irgendwie ätzend.
Bei einfachen Models, welche mir nur Daten aufbereiten und liefern, diese speichere ich einfach in ObservableCollection. Aber sobald halt bisschen mehr Logic kommt und ich Properties mit validierungen etc behandeln muss...

Aber sind halt die Grundzüge die man ziehen muss und die kleine fummel Arbeit anfangs.

Gruß.

5.299 Beiträge seit 2008
vor 9 Jahren

@FZelle: Wie jetzt - heißt das, es gibt keine durchkonzipierte Standard-Vorgehensweise für das Problem?
In meinen Augen ist das eine ziemliche architektonische Katastrophe, wenn dieselben Objekte redundant in verschiedenen Listen geführt werden.
Und das Beispiel ist ja noch simpel.

@Exis: Was bedeutet "verbinde die ViewModel zum Model mit einer Komposition" - ist das ieine Technik, die Redundanz aufzulösen?

Der frühe Apfel fängt den Wurm.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Ich meine mit Komposition die Beziehung zwischen den Klassen. Also ich erstelle im Konstruktor des ViewModels halt das Model. Es gibt ja auch einige die das Model in einer art Controller Klasse erstellen und dieses dann im ViewModel übergeben. Ich halte das aber eigentlich für nicht sinnvoll, weil ich ja schließlich so das ViewModel lösche, das Model aber noch existiert... Und das bringt mir ja nichts dann.

Gruß.

F
10.010 Beiträge seit 2004
vor 9 Jahren

Also ich erstelle im Konstruktor des ViewModels halt das Model

Das Viewmodel sollte eigentlich keine Models erzeugen, sondern aus der Datenschicht bekommen.
Wenn du im VM erst ein Model erzeugen musst, hast du irgendwas falsch gemacht.

@ErfinderDesRades:
Alle MVC Muster ermöglichen verschiedene Sichten auf ein und das selbe Model, nur ohne die Sicherheiten von MVVM, denn die anderen Muster schränken die Sichtbarkeiten sehr schlecht oder garnicht ein.
Man muss schon lange aufpassen was man macht, wenn man mehr als einen 2 Zeiler schreibt.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

In wie fern aus der Datenschicht? Also habe ich eine Klasse, als art Controller und in der erzeuge ich meine Models alle und diese übergebe ich dann ins ViewModel? Wo wäre dann der grobe unterschied, ob ich diese nun im ViewModel konstruktor erzeuge oder erst in eine art Controller und dann übergebe. Das mit dem übergeben macht ja dann das Problem, dass ich die einzelnen Objekte zweils zwei mal löschen muss. Das ViewModel und das Model.

Gruß.

4.931 Beiträge seit 2008
vor 9 Jahren

Hallo Exis,

lies dir ersteinmal [Artikel] Drei-Schichten-Architektur durch.
Die "Business Logic"-Schicht erzeugt (und verwaltet) die Models, welche sie aus der Datenschicht (=Persistenzschicht) erhält. Und die ViewModels greifen dann auf die für sich benötigten Models zu.
Daß man bei Veränderungen der Daten (Editieren, Hinzufügen, Löschen) dann doppelten Code (für jeweils ViewModel und Model) hat, ist eben der Preis für die Trennung der Schichten. Bei geringer Datenmenge können sich die ViewModels auch einfach alle Daten neu ziehen.

Bei größeren Projekten hat man sogar häufig noch zwischen den ViewModels und der BL noch Service-Klassen sitzen, welche die Aufgabe der view-bezogenen Datenhaltung übernehmen - damit die ViewModels selber diese nicht übernehmen müssen - gerade wenn mehrere ViewModels die gleichen (oder ähnliche Daten) anzeigen, bspw. die Anzeige einmal als Liste und einmal als hierarchischer Baum.

Für kleinere Projekte ist dies noch nicht so relevant bzgl. der verschiedenen Schichten und Klassen.

Es ist jedoch schwierig, für Anfänger geeignete Beispiele zu finden, welche einerseits gleich die komplette Trennung der Schichten enthält, gleichzeitig aber nicht so komplex ist, daß der Anfänger nicht überfordert wird.
Je größer die Projekte werden, desto mehr sollte man sich der strikten Trennung der Schichten und Aufgaben bewusst werden (Stichworte: Separation of Concerns, Single Responsibility Principle, SOLID, ...).

F
10.010 Beiträge seit 2004
vor 9 Jahren

@Exis:

dass ich die einzelnen Objekte zweils zwei mal löschen muss.

Wir sind hier nicht bei C, wo man irgendwas freigeben muss.

5.299 Beiträge seit 2008
vor 9 Jahren

Das doppelte Löschen hat doch mit der Sprache nix zu tun, sondern ergibt sich einfach daraus, dass bei verschachtelten Datenmodellen der MVVM-Pattern erfordert, dieselben Daten an unterschiedlichen Orten und in unterschiedlichen Listen zu verwalten - siehe das Beispiel mit den CarParks und Cars.

Der frühe Apfel fängt den Wurm.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Die Drei Schichten Architektur habe ich natürlich gelesen. Vor allem in bezug auf MVC. Allerdings habe ich mir das bei MVVM ein wenig anders gedacht.
Dann muss ich echt so vorgehen das wenn ich auf einen Button drücke, ich in einer Datenschicht das Model und das ViewModel erstelle und dann weise ich dem ViewModel noch das Model zu.

Naja, dann muss ich halt jedes Objekt doppelt löschen (CarParkViewModel und CarParkModel)... Wahrscheinlich werde ich das in einer art Destructor lösen, welcher beim löschen des ViewModels aufgerufen wird und ich dort das Model lösche...

Gruß.

16.807 Beiträge seit 2008
vor 9 Jahren

Stell Dir das einfach so vor.

Du hast ein Model, das sich _Account _nennt.
Das Model hat neben dem Namen des Benutzers auch das Passwort und das Land.

Die Selektion des Landes soll nun beim Registrieren über eine Selectbox erfolgen, in der alle Länder aufgeführt sind.
Irgendwie müssen nun die Länder in die View kommen. Die kannste ja schlecht über das Model an die View geben, also brauchst Du ein ViewModel, das die Liste aller Länder hat. Das ganze nennt sich dann AccountRegisterViewModel.

Dann gibt es ein weiteres Fenster, das sich AccountEdit nennt.
Der Nutzer soll nun gar nicht alle Elemente ändern können, sondern nur ausgewählte.
Hier hast Du also ein AccountEditViewModel.

Trotzdem wird aus allen ViewModels letzten Endes ein Model repräsentiert: Account.
Nur eben zugeschnitten auf den jeweiligen UseCase. Und der UseCase ist immer der zielgerichtete Rahmen, um den es geht.

Letzten Endes arbeitest Du in der View NUR mit dem ViewModel.
Was Du dann über das ViewModel an das Model weiter reichst, das weiß die View nicht und muss bzw. soll die View auch nicht wissen.
Du wirst am Ende sehr viel mehr ViewModels als Models haben; einfach aufgrund des vielen verschiedenen UseCases für ein einziges Model.

5.299 Beiträge seit 2008
vor 9 Jahren

@Exis: Oder du gehst zurück auf die in post#1 aufgrund gesunden Menschenverstandes gestellte Frage.
Alle die dolle Pattern sind alle ganz doll, aber das dollste Prinzip (es ist kein Pattern) ist KISS - "keep it simple, stupid!"

@Abt:
Die Länder zähle ich mit zum Model (nicht Viewmodel), nicht nur den einzelnen Account.
Von irgendeiner Persistenzschicht müssen die ja auch geladen werden.

Und natürlich kann man die an den View geben - mag sein ist nicht die reine Lehre.
Grad zum Registrieren und Editieren würde ich vmtl. keine verschiedenen ViewModelse mir ausdenken.
Das würde bei mir IEditableObject implementieren, und dann könnte ich dasselbe Model sowohl fürs Registrieren als auch fürs Editieren verwenden.
Und auch ein UserControl würde ich mir ausdenken, mit dem man son Account in beiden Dialogen (Register, Edit) präsentieren kann.
Prinzip Wiederverwendbarkeit.

Der frühe Apfel fängt den Wurm.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Letzten Endes arbeitest Du in der View NUR mit dem ViewModel.
Was Du dann über das ViewModel an das Model weiter reichst, das weiß die View nicht und muss bzw. soll die View auch nicht wissen.
Du wirst am Ende sehr viel mehr ViewModels als Models haben; einfach aufgrund des vielen verschiedenen UseCases für ein einziges Model.

Kommt doch sicher drauf an wie man es entwickelt? Kann mir nicht vorstellen das ich mehr VM's als Models habe, eher umgekehrt.

Bestimmte Models speicher ich einfach in eine Collection, statt ne eigene ViewModel Klasse zu machen. Ist ja nicht immer Sinnvoll.

Aber es ist halt noch irgendwie doof, mit dieser doppelten Erstellung des einzelnen Objektes. Stört mich irgendwie, aber muss ich mich wahrscheinlich dran gewöhnen. Bastel ja gerade an mein Übungsprogramm.

Besteht derzeit halt aus einer View, paar Benutzeroberflächen, drei ViewModels (Main, CarPark, Car), daz dann zwei Models (CarPark, Car) und zwei Zusatzklassen. Bei den Zusatzklassen handelt sich um eine Main-Klasse wo Grundzüge erstellt werden und eine Bereitstell-Klasse wo ich paar Models bereitstelle, da ich keine Datenbankverbindung, XML-Loading etc nutze. Vor allem weil man so eine Bereitstell-Klasse ja immer gebrauchen kann, da ich es nicht abkann wenn ich fürs kurze Testen immer eine XML Datei etc laden muss. 😄

Gruß.

16.807 Beiträge seit 2008
vor 9 Jahren

Kommt doch sicher drauf an wie man es entwickelt? Kann mir nicht vorstellen das ich mehr VM's als Models habe, eher umgekehrt.

In 99.9% der Fälle hast Du mehr ViewModels als Models. Einfach aufgrund der vielen UseCases für ein einziges Model.
Selbst in Deinem MiniBeispiel (Car, Park) wirst Du mit sicherheit ein Vielfaches an VMs haben.

Ein ViewModel ist für das Gesamtkonzept immer sinnvoll; aber viele sehen das dann nicht mehr so eng.
Wenn Du in einem größeren Team an einer größeren Anwendung arbeitest, dann wirst Du sehr schnell sehen wie hilfreich die Abstraktion der einzelnen Schritte durch ViewModels ist. Und ja natürlich kann und wird der Aufwand sehr schnell steigen und mehr Zeit in Anspruch nehmen; aber das ist auch nicht unbedingt der Sinn oder der Zweck.

Mit einer sauberen Trennung mit Hilfe ViewModels lassen sich Teile der Anwendung viel leichter modularisieren und testen.

PS: auch eine XML stellt eine Datenschicht dar und Du solltest diese genauso abstrahieren wie jeden DAL.
Der Anwendung muss egal sein, ob die Daten aus einer SQL- oder einer XML-Datenbank kommt.
Genau deswegen gibt es die Schichtentrennung und Technologien wie zB. Dependency Injection.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

mmh... irgendwie weiß ich noch nicht so recht. Ich habe mal ein anderes Beispiel. Eins wo es keine Datenschicht geben würde.
Ich habe folgende Klassen: Game, Dice oder z. B. Figure und einen Cast, welcher bei dem Würfeln z. B. das "würfeln" übernimmt und auswertet.

Wie würde ich das in das ViewModel übertragen und wo würde ich was erstellen? Der Cast gehört in kein ViewModel, ist halt sozusagen eine Helper-Klasse. Aber was ist mit Game und Dice? Ich hätte dann eine GameViewModel und eine DiceViewModel. Das Game enthält eine Liste an Dices und das GameViewModel somit eine liste an DiceViewModel. Nur wo wird nun das erstellt? Also eher gesagt, wo werden die Models erstellen? Diese könnte ich doch direkt im Konstruktor des ViewModel erstellen? Oder soll ich irgendwie eine Art "Controller" haben, der mir ein Game erstellt, paar Dices erstellt. Diesen Controller jedoch erstelle ich in einer MainViewModel, in der erstelle ich die GameViewModel und in der GameViewModel erstelle ich die DicesViewModels. Und übergebe den jeweiligen ViewModels immer die Models von Controller? Falls das richtig ist, verstehe ich nicht ganz wieso. Finde diese art irgendwie schwachsinn. Oder denke ich da falsch? Eher so, das ich ja z. B. die Dices woanders auch aufrufen lassen könnte, so habe ich ein Model z. B. Dice_1 und dazu kann ich ein DiceViewModel_1 und DiceViewModel_2 haben und beiden allerdings greifen auf Dice_1 zu und so kann ich in DiceViewModel_1 Commands einrichten welche im DiceViewModel_2 nichts zu suchen haben?

Gruß.

16.807 Beiträge seit 2008
vor 9 Jahren

Hast Du mal die WPF Serie von Coffeebean durchgelesen?
Da wird das nämlich behandelt...

Der Cast ist keine Helper-Klasse, sondern das ist Business-Logik. Würfeln ist schließlich (ein Teil) der Kern-Logik dieser Anwendung.
Und die Business-Logik gehört zum Model-Layer, wie alles, was "reusable" ist.

Und das Model erstellt i.d.R. die Business-schicht, zB ein Services.
Evtl. solltest Du wirklich mal sauber ein Tutorial durcharbeiten...denn das hier sind ja alles Anfangsfragen, die in den ersten 1-2 Stunden geklärt werden und noch gar nicht komplexere Punkte erreicht hat.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Wenn du diese meinst: http://offering.solutions/2014/09/02/wpf-basics-how-to-make-first-steps-of-databinding/
Ja diese habe ich durchgelesen, jedoch tu ich mir sehr schwer dabei auf Englisch Tutorials durchzuarbeiten, bin nicht der beste im englischen. Deswegen bin ich bei Tutorials lieber auf der deutschen Seite. Nachschlagewerke benutze ich öfters mal auf Englisch aber bei Tutorials habe ich da echt meine Probleme das immer im Kopf erst zu übersetzen, dann habe ich dort schon Fehler und dann noch umsetzen... Ich habe einige deutsche Tutorials durchgearbeitet, nur habe ich kein vernünftiges gefunden was meine Frage vernünftigt aufgreift.

Und das mit dem Cast bezog sich auf eine Helper-Klasse für den Würfel, also halt die Logik dafür und nicht als Helper-Klasse für das Projekt an sich. Sorry.

Gruß.

16.807 Beiträge seit 2008
vor 9 Jahren

MVVM ist sooo weit verbreitet; dafür gibts selbst deutsche Tutorials auf YouTube, die Deine Fragen in den ersten 30 Min klären sollten.

Gewöhn Dir sowas wie "Helper" oder "Common" gar nicht erst an und benutze dafür gebräuchliche Bezeichnungen, wie zB eben die Businss-Logik.

5.299 Beiträge seit 2008
vor 9 Jahren

Meine Erfahrungen mit utube-Tutorials sind aber unterirdisch grottenmäßig schlecht.
Also wenn du dir ein Tut von da antust, lass dir erstmal von jmd., dem du fachlich vertraust, bestätigen, dass das gut ist.
Sonst lernst du von utube sowas von Müll...

Und ich denke nicht, dass sich solch in 30min klärt. Etwa diese schaurige Doppel-Verwaltung von Listen habe ich noch nirgends in einem Tut ausgesprochen gefunden.

Die Tuts mögen schmissig daherkommen, aber TeufelDetail malwieder.

Der frühe Apfel fängt den Wurm.

F
10.010 Beiträge seit 2004
vor 9 Jahren

Das Problem ist, wenn man als Anfänger so etwas ansieht, kommt man nicht darauf, das erstmal das Problem vor der Tastatur sitzt.

Wenn man also nach dem "meistern" des Basics auf MVVM stößt, ohne Ahnung von allgemeiner Architektur zu haben, dann wirkt vieles etwas überbordet.

Und für ein Programm das 2 Modelle und 3 Masken hat, kann man es sich sicher lich sparen.
Wenn man aber mal, und dafür sind solche Patterns gedacht, zig verschiedene Modelle und mehr als das Masken hat, macht die Separation viel mehr sinn.
Wenn das dann noch von Kunden benutzt werden soll ( egal ob in der eigenen Firma oder echte Kunden ) dann wird Wartbarkeit das Thema, und dann macht sowas wirklich vieles einfacher.

Und dank T4 und Snippets, ist auch nur das Ausmass der Sourcen grösser, nicht der Anteil den man selber schreibt.

E
Exis Themenstarter:in
51 Beiträge seit 2014
vor 9 Jahren

Ich geh meistens davon aus, das ich das Problem bin und nicht die Sprache 😄 Wie sollte es auch anders sein.

Ich baue mein Übungsprogramm nun auf Basis von den letzten Post von mir. Also das mit dem Beispiel von dem einen Model und dazu zwei ViewModels. Muss mir nur noch überlegen wie ich das alles am besten aufbaue.

O
461 Beiträge seit 2009
vor 7 Jahren
Frage zum "Model"

Hallo, baue oder besser gedagt möchte ich auch eine der nächsten Anwendungen mit MVVM ertellen. Ich habe auch schon ein wenig damit gearbeitet.
Ich habe mir mal ein einfaches Besipiel genommen, das z.B. von Rheinwerk Computing: Visual C# 2012 , Kapitel 28.5 MVVM-Pattern.
Da geht es wie in den meisten Beispielen einfach zu. Ein Model in Form einer Person (Vorname, Nachname) eine View und ein ViewModel. Die drei Komponenten sind erstellt. Nun wird Im MainWindow zuerst einmal eine Instanz von Model an das ViewModel übergeben, was ich verstehen kann. Ich ändere nun Daten per CodeBehind (übergebe einen anderen Vornamen), und das ViewModel bekommt die Änderung mit. Das verstehe ich auch. Dann habe ich aber im Code dann mal das Model angeschaut, als die Änderung durchgeführt wurde, es hatte immer noch den Vornamen der zuallererst festgelegt wurde. Sollte sich der nicht auch ändern, sobald im View oder im CodeBehind der Vorname geändert wird???
Kann man das so verstehen, was ich meine?? Ansonsten könnte man sich das Model auch sparen ??

3.003 Beiträge seit 2006
vor 7 Jahren

Da geht es wie in den meisten Beispielen einfach zu. Ein Model in Form einer Person (Vorname, Nachname) eine View und ein ViewModel. Die drei Komponenten sind erstellt. Nun wird Im MainWindow zuerst einmal eine Instanz von Model an das ViewModel übergeben, was ich verstehen kann. Ich ändere nun Daten per CodeBehind (übergebe einen anderen Vornamen), und das ViewModel bekommt die Änderung mit. Das verstehe ich auch. Dann habe ich aber im Code dann mal das Model angeschaut, als die Änderung durchgeführt wurde, es hatte immer noch den Vornamen der zuallererst festgelegt wurde. Sollte sich der nicht auch ändern, sobald im View oder im CodeBehind der Vorname geändert wird???

Um zu verstehen, was du meinst, muss man sich das Kapitel mal anschauen (gut, dass du's erwähnt hast). Ich hab das gerade getan und bin einigermaßen verärgert, muss ich sagen. Nicht nur, dass auch hier aus meiner Sicht kein MVVM implementiert wird, nein, es wird auch noch kaputt implementiert.

Ich versuch's mal auseinanderzupopeln 😉.

a) das ViewModel ist keines, vielmehr handelt es sich um einen Wrapper (eine vorgeschaltete Klasse sozusagen) um ein POCO, also um ein normales Objekt. Nur ist der Wrapper leider auch kaputt implementiert, denn er implementiert die Eigenschaften seines Objekts (_Model, und by the way, verletzt der Autor hier auch Namenskonventionen...no-go für ein veröffentlichtes Buch) neu. D.h. das _Model hat Namen und Alter, und der Wrapper hat diese zwei Eigenschaften auch, reicht sie aber nicht weiter an das Model. Richtig wäre zB gewesen, auf die entsprechenden Eigenschaften von _Model weiterzuleiten und im Set-Fall ein NotifyPropertyChanged abzuschießen. DANN wäre der wrapper ein halbwegs okay-ish implementiertes MVVM-Model (und KEIN ViewModel). Das Model in MVVM bildet das Modell der dargestellten Daten ab, und ist KEIN Business-Model.

b) Aus der oben erwähnten nicht-weiterleitung erklärt sich auch das von dir beobachtete Verhalten. Da das "ViewModel" (es heisst nunmal so, auch wenn's keins ist) die Änderungen nicht weiterreicht, können die Änderungen auch nicht im POCO ankommen. Wie auch.

c) wenn in einem BUCH, das viele Anfänger als Lernhilfe benutzen, das ViewModel im Code-Behind instanziiert wird, nein, allein schon, wenn man in dem Buch dem Leser den Code-Behind überhaupt ins Gedächtnis ruft, dann hat man als Lehrmittel versagt. Ehrlich, das geht gar nicht. Denn der Effekt ist genau, was du gemacht hast: einfach im Code-Behind mal eine Eigenschaft gesetzt. Warum auch nicht, scheint ja okay zu sein. 🤔

Also, das Kapitel MVVM hätten sie ganz weglassen sollen. Das ist peinlich. Vergiss bitte, dass du's gelesen hast 😉.

LaTino

EDIT: noch einmal zur Klarstellung: im Optimalfall implementiert das Model im MVVM bereits Schnittstellen wie INotifyPropertyChanged, um das Binden zu erleichtern. Ist das nicht der Fall - beispielsweise, weil man die Modelklassen fertig bekommt - dann muss das ViewModel die einzelnen Eigenschaften nachimplementieren.

What if your model classes do not implement the required interfaces?
Sometimes you will need to work with model objects that do not implement the INotifyPropertyChanged, INotifyCollectionChanged, IDataErrorInfo, or INotifyDataErrorInfo interfaces. In those cases, the view model may need to wrap the model objects and expose the required properties to the view. The values for these properties will be provided directly by the model objects. The view model will implement the required interfaces for the properties it exposes so that the view can easily data bind to them.

Das bedeutet, nur in diesen Fällen muss tatsächlich jede benötigte Property vom ViewModel "ummantelt" werden - dann aber für JEDES betroffene Model. Das würde etwa so aussehen:


//zwei Klassen, die wir als Model benutzen müssen, und die wir nicht erweitern dürfen
class Person
{
   public string Name { get; set;
   public int Age { get; set; }
}
class Location
{
   public string Name { get; set; }
   public int ZipCode { get; set;
}
class MainViewModel : INotifyPropertyChanged //das ViewModel des MainWindow
{
    //dargestellt werden soll der Name einer Person, und die Postleitzahl eines Orts
   private Person _selectedPerson = new Person();
   private Location _selectedLocation = new Location();

    public string SelectedPersonName 
   {
        get { return _selectedPerson.Name; }
        set 
        {  
             _selectedPerson.Name = value; 
             OnNotifyPropertyChanged("SelectedPersonName");
             HasUnsavedChanged = true;
        }
    }
    public string SelectedLocationZipCode 
   {
        get { return _selectedPerson.Name; }
        set 
        {  
             _selectedLocation.Name = value; 
             OnNotifyPropertyChanged("SelectedLocationZipCode");
             HasUnsavedChanged = true;
        }
    }
    //die Properties, an die wir nicht binden wollen, implementieren wir auch nicht!
   //andere Eigenschaften des Views, die das ViewModel kontrollieren können soll
   private bool _hasUnsavedChanges;
   public bool HasUnsavedChanges //könnte man zB an den Aktiv-Status eines Savebuttons binden
   {
         get { return _hasUnsavedChanges; }
         set 
         {
             _hasUnsavedChanges = value;
             OnNotifyPropertyChanged("HasUnsavedChanges");
         }
    }
}

Das ist ein Ausnahmefall. Im Normalfall kann man das Model anfassen, und dann soll es auch INotifyPropertyChanged implementieren, damit dem ViewModel das Binden erleichtert wird. Dann hält das VM nur noch eine oder mehrere Instanzen des Models und verwaltet diese.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

O
461 Beiträge seit 2009
vor 7 Jahren
Unklarheiten MVVM

Hallo LaTino, danke für deine Erklärung.
Ich habe noch Fragen.

  1. Es ist also so, das man das "Model" nur mit den Properties bestückt, und "NUR PROPERTIES" enthält. Da kommen keine Methoden , Schnittstellen oder sonstiges rein, korrekt?

Das Model (die Daten) kann ja sein das man die noch einer anderen Klasse in der Applikation übergeben möchte, weil diese Klasse die Daten irgendwo archiviert oder ablegt. Macht man das eigentlich so, oder ist das falsch? Ansonsten muss im "ViewModel" dafür gesorgt werden (bei den Properties) das die "Model.Properties" auch aktualisiert werden, korrekt???

Ich bin da sehr verunsichert, ich habe mich an das Beispiel von folgendem Link angelehnt, und da wird im "Model" eine Methode für die Dateierzeugung verwendet.
Ist das korrekt, oder geht diese Lehrmaterial eigentlich auch am Ziel vorbei?

WPF: Von Spaghetticode zu MVVM – Teil 7 von 9

Ich habe gerade eine Applikationserweiterung in einem Programm das mit der CNC von Steuerungen kommuniziert.
Da müssen aus einem ASCII-File das in der Steuerung abgearbeitet wird, Parameter abgeändert werden. Dazu muss ich das ASCII-File aber erst aus der Steuerung auf die Festplatte des Maschinen-PC kopieren, dann die Parameter auswerten, darstellen (in View) damit sie der Bediener anpassen kann, dann wieder auf die Festplatte zurückkschreiben und in die CNC zurück kopieren.

Diese ganze Kopiererrei und Bearbeitung vom ASCII-File würde ich nur in der "ViewModel" machen, oder?
Dann ist noch das Problem, das ich das Zurückschreiben in die CNC in einer speziellen Klasse für die CNC-Kommunikation habe. Kann ich dann an die das "Model" mit dem veränderten ASCII-File übergeben, oder macht man dann diese Kommunikation mit der CNC auch im "ViewModel" ?? Dann muss man die CNC-Kommunikation in mehrern "ViewModels" abbilden, sofern man mehrere "View" hat ??

16.807 Beiträge seit 2008
vor 7 Jahren

Ein Model ist ein Datencontainer während das ViewModel die Inhalte einer Seite/eines Fensters repräsentiert sowie funktionale Daten enthält.
Das ist unabhängig von MVVM so und gibt zB auch für MVC.

=====
Als Beispiel das Fenster eines Registrierungsseite.
Dort kannst Du das Land auswählen und einen Benutzernamen setzen.

Das Model hat nur das ausgewählte Land inne, sowie den Benutzernamen.

Das ViewModel hingehen kennt die Liste aller Länder (funktionale Daten), die Du auf der Seite auswählen kannst.
=====

Das Model kannst Du an beliebigen Stellen verwenden, wohingegen ein ViewModel in der Regel nur eine spezifische Seite/Teil einer Seite repräsentiert.
Das ViewModel übernimmt keine Applikationslogik! Dafür ist der Businesslayer zB in Form von Services verantwortlich; das gehört nicht in die Oberflächenschicht!

3.003 Beiträge seit 2006
vor 7 Jahren

@Abt, Microsoft definiert das Model innerhalb von MVVM etwas anders, siehe Zitat unten.

  1. Es ist also so, das man das "Model" nur mit den Properties bestückt, und "NUR PROPERTIES" enthält. Da kommen keine Methoden , Schnittstellen oder sonstiges rein, korrekt?

Eigentlich schrieb ich oben das exakte Gegenteil davon. Das, was du beschreibst, ist eine Ausnahme. Sie kann vorkommen, wenn man bereits mit einem fertigen Model arbeitet, das beispielsweise aus dem Business Layer stammen kann. Hat man diesen Fall, muss das VM dieses Modell wrappen. Wenn man das Model selbst definieren kann (zum Beispiel, weil es sich um eine Standalone-WPF-Anwendung handelt), kann und sollte das Model durchaus mehr enthalten.

The Model Class
The model in the MVVM pattern encapsulates business logic and data. Business logic is defined as any application logic that is concerned with the retrieval and management of application data and for making sure that any business rules that ensure data consistency and validity are imposed. To maximize re-use opportunities, models should not contain any use case–specific or user task–specific behavior or application logic.

Zu deinem konkreten Fall.

MVVM definiert die Trennung der Verantwortlichkeiten in deiner UI. Ich möchte aber stark bezweifeln, dass es Aufgabe deiner UI sein sollte, ein ASCII-File von einer Steuerung zu kopieren und zu parsen. Die Zuständigkeit der UI endet dort, wo die Aufgabenstellung lautet "stelle DIESE Daten dar". Das heisst du benötigst etwas, das völlig unabhängig von der UI arbeiten kann (ich rede nicht von einem Programm, nur von einer Bibliothek) und in der Lage ist, die Daten zu extrahieren, die später (zb in der UIm, aber auch, was weiss ich, in einem Webservice, der den Livestatus liefert) verwendet werden sollen. Für die Gegenrichtung gilt das auch so.

Konkret:

  • Projektmappe
    • Projekt WPF
    • Projekt CNC-Kommunikation (Bibliothek)

Wobei das WPF-Projekt durchaus Klassen aus der Bibliothek verwenden darf, aber nicht wissen muss, was genau die machen. LoadData() und SaveData() im einfachsten Fall.

Diese ganze Kopiererrei und Bearbeitung vom ASCII-File würde ich nur in der "ViewModel" machen, oder?

Nee. Das ViewModel darf maximal sowas in der Art von


ObservableCollection<MvvmModelClass> example = ConvertToMvvmModel(CncCommunication.DataProvider.Load());

Im besten Fall weiss kein Teil deiner WPF-Anwendung irgend etwas von ASCII-Dateien.

Siehe auch [Artikel] Drei-Schichten-Architektur
MVVM ist nur eine dieser Schichten. (Und definiert, wie diese eine Schicht aufgebaut sein kann.)

LaTino

EDIT: Implementing the MVVM Pattern
Immer beachten, dass nichts davon in Stein gemeißelt ist. Kein Pattern der Welt ist das. Die richtige Antwort auf die Frage nach der korrekten Implementierung von MVVM heißt immer "...es kommt darauf an".

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

5.299 Beiträge seit 2008
vor 7 Jahren

Ich kann ja mal versuchsweise auch mein Senf abgeben.
Sehr Gefallen habe ich an dieser klaren Aufgabenstellung (ich habs halt gern konkret):

Da müssen aus einem ASCII-File das in der Steuerung abgearbeitet wird, Parameter abgeändert werden. Dazu muss ich das ASCII-File aber erst aus der Steuerung auf die Festplatte des Maschinen-PC kopieren, dann die Parameter auswerten, darstellen (in View) damit sie der Bediener anpassen kann, dann wieder auf die Festplatte zurückkschreiben und in die CNC zurück kopieren. Für mich wäre erste Aufgabe, ein Datenmodell zu konstruieren, was die Verhältnisse einer Cnc-Steuerung abbildet.
Und zwar habe ich ein Faible dafür, relational-datenbänkerisch zu denken, also in Begriffen von Entitäten und Beziehungen.
Nu hab ich keine Ahnung von CNC, vermute aber, es gibt an Entitäten vlt.
Werkzeug
Werkstück
Bearbeitung
CncProgramm

Eine Bearbeitung stelle ich mir vor als den zeitlichen Einsatz eines Werkzeuges am Werkstück
Bearbeitung ist also eine Art Zuordnung von 1 Werkstück zu 1 Werkzeug - relational gesehen also beiden untergeordnet
Ein Programm ist eine Liste von Bearbeitungen, also den Bearbeitungen übergeordnet.

Ich komme also zu so einer relationalen Beziehungs-Struktur, die meine 4 Entitäten verknüpft:

CncProgramm => Bearbeitung
Werkzeug => Bearbeitung
Werkstück => Bearbeitung

Das wäre bei mir das Model, und das würde ein Cnc-Programm abbilden (nee, sogar mehrere - jede Entität entspricht ja einem Datentyp, und davon kann man viele Objekte instanzieren).
Das Modell wäre allein der Realität verantwortlich, auf Erfordernisse einer evtl. Präsentation braucht es keinerlei Rücksicht zu nehmen (bei mir darf es das aber, also Sortierbarkeit, NotifyPropertyChanged etc sind doch was nettes).
Und ein DataProvider (or whatever) müsste geschaffen werden, um aus einer Ascii so ein Modell auszulesen, bzw. so ein Modell wegzuschreiben.

Als nächstes muss man sich ein View überlegen, wie man was von dem Model anzeigen will und für Manipulationen verfügbar macht.
Optimalerweise kriegt man das ganz abstrakt komplett auskonzipiert, das wäre dann das Konzept des Viewmodels.
Und dann muss man was basteln, um die Model-Objekte ins Viewmodel rein/raus - zu transferieren.
Das kann auch sehr einfach sein, weil wenn die Model-Klassen zur Präsentation geeignet sind, kann man sie ja direkt in Listen des Viewmodels einfüllen.
Also verstößt nicht gegen MVVM, wenn das Viewmodel Model-Klassen enthält, sodass letztendlich der View via Databinding direkt die Anpressdruck-Property einer Bearbeitung-(Model-Instanz) erhöht oder sowas.

Was haltet ihr davon?
Also meine(?) Kern-Ideen:
Das Model modelliert die Realität einer Cnc-Steuerung (und vmtl. wird das relational modelliert sein müssen)
Das Viewmodel modelliert die Fensterle und was darauf herumfährt. Falls opportun darf es dabei auch Model-Klassen integrieren, ansonsten muss es halt spezielle VM-Klassen verwenden.
Mindestens eine spezielle Viewmodel-Klasse gibts immer, schon allein um für Buttons/Menüs eine Basis bereitzustellen.

Und es entstehen 2 "Umfüll-Stationen"

Ascii <=> Model
Model <=> Viewmodel

Der frühe Apfel fängt den Wurm.