Code Verbesserung für MVVM

Also PropertyChanged im Getter werfen macht keinen Sinn, weil da ja nichts gesetzt wird. Du musst da schon noch einen Setter hinzufügen.
Außerdem, warum gibst Du das Model explizit im Konstruktor mit? Instanziiere das doch im ViewModel.
Architektonisch verstehe ich nicht ganz, was Du in Deinem ViewModel machst. Du wirfst da irgendwie Model und ViewModel-Properties wild durcheinander. Der Sinn wäre eigentlich in einer Methode ​GetMeasuredValue die Eigenschaft ​MeasuredValue zu setzen und nicht diese zurückzugeben, nachdem das intern im Model anscheinend gesetzt und somit automatisch in der Property aktualisiert wurde. Außerdem müsstest Du das dann über Commands etc. steuern.

Für Deinen ComPort habe ich Dir ja bereits die Idee gebracht, dafür eine eigene Klasse zu bauen und diese dann in die Liste bzw. ObservableCollection (besser) zu packen. Die ObservableCollection ist auch nicht viel komplexer und kann syntaktisch genauso verwendet werden. Binden kannst Du ja ohne Probleme an die Eigenschaften der Klasse ​ComPort, sodass diese auch im View angezeigt werden können.
​this kannst Du btw weglassen und es sollte wenn ​_mainModel heißen.

Grüße

MichaHo schrieb:

Bevor ich daher weiter mache, frag ich nach Eurer Meinung/Erfahrung/Tips.

Bezüglich dessen, hier noch ein paar Anregungen von mir:

1.) Versuche zwischen Properties, welche du nach außen greifbar machen willst, und privaten Membervariablen, welche du nur im lokalen Kontext - deiner Klasse - verwenden willst. Es macht bspw keinen Sinn eine private Membervariable, die du nur lokal verwendest, als Property zu kennzeichen (Klasse MConnection).
2.) Wenn du Sachen, wie IP Adressen oder Hostnamen, welche sich mit .NET Framework Klassen/Strukturen darstellen lassen, verwendest, dann ziehe diese den primitiven Datentypen/selber gemachten Datentypen vor. In deinem Code etwa verwendest du für deinen Server eine Property Host vom Typ String. Hier böte sich eine Property Host vom Type IPAddress an. Warum, dazu komm ich gleich noch.
3.) Wenn du dein ViewModel mit Testdaten füttern willst, kannst du hergehen und dir im VS Desginer einer neue XAML Datei erzeugen lassen. Dies musst du dann aber über die Eigenschaften als DesignData kennzeichen. Dann nur noch in die Resourcen des Views einbinden und du hast Testdaten in der Vorschau (kannst z.B. das Aussehen der Daten in einer ListView testen/dir ansehen). Hierzu brauchst du aber parameterlose Konstruktoren. Um dies zu erreichen, empfehle ich dir bei jeder Klasse (oder zumindest bei der allerobersten Basisklasse, welche du im ViewModel verwendest - in deinem Fall MConnection eben einen Default-Konstruktor einzubauen, welche die Properties auf default Werte und eine Property, welche anzeigt, ob die Datenquelle verwendet werden kann, entsprechend setzt. Die kann dann meinetwegen IsUsable heißen und vom Typ bool sein. Ich hab deswegen in Punkt 2 geschrieben: Framework Datentypen verwenden, da du hier z.B als Defaultwert als IP Adresse 0.0.0.0 angeben kannst. Wenn du hier als Datentypen IpAddress angibst, kannst du auf if (host == IpAddress.None) prüfen.
4.) Mach Statusänderungen (Verbindung aktiv/geschlossen) nicht selber aus, sondern lasse sie dir über Getter liefern
5.) Underscores (also _ vor Variablennamen würde ich grundsätzlich nur bei sog. Backing Fields machen. Also wenn eine Klasse eine Property hat, welche das PropertyChanged Event auslöst. Hier ist es sinnvol sich eine private Variable zu machen, die so heißt, wie die Property, nur mit einem Underscore. Wenn du den Wert durch eine Funktion/Prozedur setzt, empfielt es sich die Property CamelCase, das BackingField lowerCamelCase mit Underscore/Unterstrich und den Parameter nur lowerCamelCase zu machen.

Lg Radinator

MichaHo schrieb:

Es gibt nun eine MainModel Klasse und eine MainViewModel.

Das findich auch sehr fragwürdig.
Welche Aufgabe hat das, was bei dir "Mainmodel" heisst (und warum heisst es nicht wie seine Aufgabe ist)?
Welche Aufgabe hingegen hat das MainViewmodel? Nur alles kapseln, und dann das gekapselte doch durchreichen ist keine Aufgabe, sondern nur ganz viel doppelt gemoppelter Code, und damit bäh!
Viele MVVM-Propheten, bes. c#ler, propagieren ja diese doppel-moppelei, aber das ist falsch verstandenes MVVM - sagen zumindest andere.

Wie dem auch sei - zumindest mitte Mainmodels: In meiner Welt gibts nur ein MainViewmodel, das ist das Root-Objekt mit lauter Properties - einige davon sind Viewmodel, einige Commands.
Manchmal nenne ich das MainViewmodel auch (ungenau) "Mainmodel" - nur beides - MainViewmodel und Mainmodel - das gibts nicht.

das mit deinen Helpers und den Testdaten war mir zu hoch

naja, du hast das Projekt jetzt ja geladen, uns siehst, wie die Testdaten inne Xaml-Vorschau sofort sichtbar sind: sobald man ein Binding richtig setzt, erscheinen inne Vorschau richtige Daten: "Person1, Person2, Person3,..."

Zumindest der Nutzwert, und wie's inne Praxis dann rauskommt, sollte dir also nu nicht mehr "zu hoch" sein.

@ErfinderDesRades Okay, das ist interessant. Also sollte man lieber direkt ans Model binden statt alles zu kapseln?

Grüße

In vielen Fällen schon.
Guck meine Sample-Solution, da hab ich spasseshalber ja noch ein Model ausgelagert aussm Viewmodel, und man sieht deutlich, dass eine der beiden Klassen ühaupt keine Aufgabe hat - ausser Verwirrung zu stiften.

Ich sehe sowas immer pragmatisch - ein Konzept-entsprechen nur um des Konzept-entsprechens Willen ist für mich wertlos, und trifft glaub die Definition des Begriffes "Dogmatismus".
Wichtig an Konzepten ist doch, dass sie Anleitung geben, Probleme zu lösen, zu vereinfachen - bzw. auch zu vermeiden.
Ergibt sich aus einem Konzept eine erhöhte Umständlichkeit ohne erkennbaren Gewinn - dann stimmt irgendwas nicht - mit dem Verständnis? mit der Umsetzung? oder gar mit dem Konzept selber?
Das sind wirklich offene Fragen, ich weiß wirklich nicht, ob ich MVVM richtig verstehe, ob ich iwelche Gewinne übersehe, oder ob andere sich irren oder whatever.
Oder sind meine Problemstellungen viel zu klein, und erst in größeren Rahmen würde sich die Voll-Ausbildung des Patterns als wirklich not-wendig erweisen?

Aber mal konkret:
Hab vor einiger Zeit an einer Zeiterfassung gewerkelt, mit Kern-Arbeitszeiten (40h-Woche), "gemessenen" Arbeitszeiten, Tätigkeiten, etc..
Wieder war Model und Viewmodel eins, weil das Model enthielt die gemessenen Arbeitszeiten, und die gemessenen Arbeitszeiten waren auch anzuzeigen - also was sollte ein zwischengeschobenes Viewmodel bringen?
Aber dann war eine Monats-Ansicht zu gestalten, und das war etwas, was das Model nicht hergab - dort gabs nur von wann bis wann wer gearbeitet hat, aber nicht nach Monaten strukturiert.
Und hier brauchten wir klar ein Viewmodel, also das Modell eines Monats, dass man das View dranbinden konnte.
Und wurde nur fürs View gebraucht - inne Datenbank hat das ja nix verloren.

Sowas ist denke ich ein Viewmodel, und dann scheint MVVM auf einmal auch mit allen 3 Schichten absolut stimmig - ich hoffe du verstehst wassich meine.

Noch ein paar Gedanke meinerseits:

MichaHo schrieb:

Du hast das Model, das liefert die Daten, egal wo die herkommen

Würde ich persönlich nicht so sehen. Die Daten bekommst du nicht vom Model sondern durch deinen Data Access Layer (DAL). Das Model ist nur das Modell, also wie im normalen OOP der Unterschied zwischen Klasse (=Bauplan) und dem Objekt. Das Model beschreibt nur WAS du anzeigen/persistieren kannst/willst/tust. Der DAL braucht Kenntniss des Model(-namespaces) und kann dir dann eine IEnumerable<T> oder einfach ein Objekt liefertn, dessen Properties du dann im ViewModel dann auf die Properties des ViewModels verteilst. Um das mit dem DAL leicht verwendbar zu machen, bietet sich hier das SOLID Prinzip an. Dazu einfach das D (Dependency Inversion) verwenden: Hierzu entweder im Kontruktor des ViewModels ein Interface erwarten, von dem es eine Klasse gibt, die dir die Daten bereitlegt oder eine LoadData Methode implementieren, welche im Konstruktor aufgerufen wird und die Daten läd (sagt ja schon der Name). Dadurch kannst du Mocking/Unit Tests fahren und schauen, ob die Daten richtig geladen werden.
Außerdem: Eine Klasse sollte immer nur eine einzige Aufgabe haben (nicht wie bei dir mehrere: ViewModel sein, also Daten bereitstellen UND die Daten auf noch aus einer Datenquelle liefern)

MichaHo schrieb:

Für verschiedene Aufagben gibt es verschiedene ViewModels

Ich würde es anders formulieren: Für jede(s) View gibt es ein eignes ViewModel. Denn das View hält ja nur die Daten bereit, das/die View zeigt sie nur an. Ob die Oberfläche in Deutsch/Japanisch/Türkisch/Klingonisch angezeigt werden soll ist doch dem View egal.

MichaHo schrieb:

eine WPF Gui, eine Android Gui, eine iOS Gui, eine Web Gui.

Irgendeine GUI, welche Datenbindung unterstützt.

MichaHo schrieb:

ich kann das Model austauschen

Wie in #1: Das Model nicht. Nur den "DataProvider", also ob die Daten in Deutsch, Englisch, Klingonisch, Türkisch aus einer DB, Text-Date oderWebService kommen sollen. Schau dich mal hier um: Lokalisierte Model Entity Wpf

MichaHo schrieb:

indem ich die Daten nicht mehr direkt aus ner Textdatei bereit stelle sondern eventuell aus ner Datenbank.

Wie gesagt: Woher du die Daten bekommst ist oder bzw sollte dem ViewModel egal sein, das ViewModel braucht nur eine Referenz auf ein Objekt, welche Daten liefern kann. Das und nur das kannst du austauschen.
Wenn du z.B. als Model die Klasse Auto hast - und sie dir auch gleich die Daten für einen Audi A7 mit x Extras liefert (was sie nicht soll, aber jetzt mal egal), dann kannst du nicht einfach hergehen und (weil du grad lustig bist) das Model, also die Klasse "Auto", durch "Mensch" austuschen, welche dir - hier auch wieder: Sinnhaftigkeit... - das Model "Mensch" meinetwegen das Objekt "Usain Bolt" leifert. Objekt "Usain Bolt" hat aber nunmal keine Property "PS", sondern nur "MaximalLeistung". Und genau hier "knallt" es. Bzw es wird dir halt einfach nix (PS und MaximalLeistung) angezeigt.
Deswegen: Nie das Model austauschen!! Immer nur die Klasse/das Objekt, welche dir die Daten liefert.

MichaHo schrieb:

kann mans wirklich weg lassen, denn dann sieht man bereist an der Schreibweise was wo hin gehört.

Ich persönlich schreib halt immer lieber this davor, da ich dann ganz sicher sein kann - auch wenn ich den Code nur überfliege - dass diese Property/diese Variable auch zu der Klasse gehört.
Außerdem: Ist halt eine alte Angewohnheit. Meist lass ich das sowieso weg, aber gerade, wenn ich Code teile und ich da nur Snippets poste, dann erleichtert es - meiner Meinung nach schon - wenn ich this verwende. Vor allem: Gesetzt dem Fall, ich poste einen Ausschnitt einer Funktion, dann ist es einfacher zu sehen: Ah, die Variable hier ist nicht im lokalen Kontext gesetzt, sondern eine Klassenvariable.

Lg Radinator

ich auch nochmal.

Also wie Radinator sagt: Model holt nicht die Daten, sondern es ist der Ort (meist ein zusammenhängendes System von Klassen), wo die (via DAL) geholten Daten reingetan werden, um inne Anwendung verfübgbar zu sein.
Anders als bei Radinator hat bei mir nicht jedes View sein eigenes Model, sondern wenn sich Elemente des Model eh schon eignen, um ein View dranzubinden - da treib ich keinen Zusatz-Aufwandt.

Ähnlich mit Dependancy-Injection: Probiers aus, und guck, obs dir Gewinn bringt.
Ich find die Kosten-Seite nicht ohne:

• DI-Container installieren/einbinden
  
• Interfaces anlegen + pflegen
  
• ganz viele Casts, und umständliche Instanzierungen
  

Die Samples, die ich gesehen habe, die waren eiglich immer viel einfacher mit einem statischen Objekt abgehandelt, wo man ebensogut die Sachen holen konnte, die man brauchte.
Und letztendlich ist so ein DI-Container auch nix anneres als ein statisches Objekt, wo man Sachen holen kann (muss man halt registrieren etc.)

ErfinderDesRades schrieb:

Anders als bei Radinator hat bei mir nicht jedes View sein eigenes Model

Da ich bisher noch keine Anwendung hatte, die mehr als 1 View hatten, bestand bei mir auch (Gott sei Danke) nicht der Bedarf, ein ViewModel für mehrere Views zu verwenden.

Allerding ist es IMHO immer eine Sache der Anwendung, OB für jedes View ein eigenes ViewModel gebraucht wird oder ein ViewModel für mehrer Views verwendet werden kann. Also von Anwendung zu Anwendung unterschiedlich. So wird ein

Allerding ist es IMHO sinnlos in einer Anwendung ein ViewModel für mehrere Views zu verwenden. So ist es bspw wenig ratsam 1 Anwendung, 1 ViewModel zu haben, wenn eine View die eigentliche Oberfläche zeigt, die zweite dann diverse Einstellungen und die dritte dann noch mal ganz anderen Content. Hier sollte man wie gesagt für jede View ein eigenes ViewModel anlegen. Und ich kann die Aussage sogar belegen: SOLID Prinzip, Single-Responsibility-Prinzip: Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine einzige Verantwortung haben solle

Lg Radinator

MichaHo schrieb:

muss ich einfach in der ViewModel (was dann die Klasse ist, die sich die Daten holt und zur Anzeige bereit stellt) nur die Daten eben abholen und in Properties ablegen

Jup

Das Ding ist tatsächlich zu klein, als dass Verbesserungsvorschläge da überzeugen könnten.
ZB gibts kein INotifyPropertyChanged, also wenn MValue sich mal ändern würde, würde die Oberfläche das nicht mitbekommen.
Und nachwievor haste im CodeBehindAlso hast noch nie ühaupt gesehen, wie man mittm Xaml-Editor Bindings "picken" kann.