Hallo @Hutti

Wennich das aus deinem Text richtig verstehe sehe ich hier ansich kein Problem dies so in einem ViewModel abzubilden.
Die ganze Sache mit dem Lasersystem und so lass mal aussen vor.

Ich nehme an du weist welche Art und Werte von Parametern von den Lasersystem zurückkommen oder zurückkommen können.

Schritt 1:
Mach ein Interfaces für die Kommunikation und die Parameter damit du hierfür "Fakes" (Mocks) erstellen kannst. So kann Beispielsweise unabhängig entwickelt werden.
Also könntest du z.b. ein Beispiel hier hochladen wo werte in die Klassen kommen als würde eine Maschine (Lasersystem) vorhanden sein.

Schritt 2:
Nun kommen "Beispielwerte" in deine Klassen mit welchen du ein ViewModel befüllen und das ganze Testen kannst.

Schritt 3:
Nun einfach den Mock gagen die echte Implementierung austauschen und schon läuft alles. Im Idealfall.

Das Problem welches ich nun habe, ich sehe aus dem Text nicht welche Werte/Paramter wie wo in welche Klasse kommen können und wie das ganze aussehen soll/muss/kann.

Vieleicht kannst du ja ein Minibeispiel schnell zusammenmachen (mit Testdaten) wo man sieht wie das am Ende funktionieren soll. Dann finden wir sicher eine Idee wie man das per MVVM abbilden kann.

Das kann eine Anwendung sein, ne Skizze, ne Animation, ein Lastenheft oder sonst was. Ich (wir) müssen uns nur auskennen. Vieleicht liegt es an mir, aber ich verstehe an dem Text nicht Wo es hakt. Auch kein Code und kein Anhang.

Grüße
Sascha

Hi.

Sieht gut aus, besser als mein Spaghetti-Code...

Also zum Verständnis, ist die Presentation der Daten hier dein Anliegen?

Wenn ja, dann... Am besten mit Master-Detail-Ansichten arbeiten, um das einzelne LaserSystem optisch Aufzuwerten, und die Seriellen-Daten (und anderes) anzuzeigen.

Das kann mit hilfe von DataTemplates in XAML gelöst werden, und kann für "Gruppen" von LaserSystemen gut aufbereitet werden.

Ich liebe ListBoxen und von einer ListView habe ich schonmal gehört.

Da hier Geräte in einer Auflistung sind, kann eine DatagridView genutzt werden, aber wir sind ja nicht mehr in den 2000er Jahren,
und mit MVVM kann ein ListenEintrag (ListBoxItem oder ListViewItem) eine eigene Datatemplate besitzen und wunderbar umgesetzt werden.

Ist ein wenig frickelig, wenn das noch nie gemacht wurde, aber ich statte die meisten Auflistungselemente mit eigener Ui-Logik aus.
Zum Beispiel ein Button, der nur den Eintrag betrifft (update, delete, refresh etc.), oder das Anzeigen von unterschiedlichen StatusMeldungen und mehr...

Das Beispiel von @Nofear23m mit den Mock-Daten und dem Interfacing, kann ich persönlich empfehlen, benutze es 'selbah' aber nie. (ECHT jetzt...?)

Falls Du auf die Idee kommst, für jeden ListBoxItem eine eigene UserControl mit eigenem ViewModel zu erstellen, lass es... Es sei denn du Produzierts für die "Börse Echtzeit-Software"...

Ich kann aus Erfahrung sprechen, das diese Vorgehensweise eher umständlich als produktiv ist.

Ich stelle mir das Viewmodel immer als das "Programm" vor und das View als das "BlingBling",
und das Model ist mittlerweile nur zum XML Import/Export und als "Komplexe Variablen Definition" verkommen.

In deinem Fall ist das verwenden von Interfacen (Schnittstellen) fast eine Notwendigkeit,
weil API-Grenzen "immah" ("Explizit mit AH am Ende") mit einem Interface versehen sein sollten.

Somit ist dann eine UI mit MockUp-Daten (VerspottungAuf-Daten?) eigentlich die beste Wahl.

Wenn der Lapidar von mir zusammgeklatschte Beitrag fragen aufwirft, dann einfach nachhaken.

Ich hoffe das der Kontext mich hier nicht getäuscht hat....

c.u. Joshi aus HH

Hallo

Wenn ich das richtig sehe gibt es zwei verschiedene Lasersystem welche unterschiedlich funktionieren. Soweit richtig?
OK, dann bau dir mal Interfaces auf (wie ein Bauplan oder ein Rezept). Für jede Art von Lasersystem (solange es nicht mehr wie 2 oder 3 sind, sonst müsste man sehen das man das Generisch hinbekommt) ein Interfaces.
Dieses beschreibt was ein Lasersystem kann/hat/macht.

Wenn du Zugriff auf diese Lasersysteme hast kannst du die "echte" implementierung der Interfaces gleich machen um zu sehen ob die Interfaces so stimmig sind.
Die Services sind auf jeden Fall eine eigene Klassenbibliothek (empfehle ich zumindest). Hier gibt es jetzt auch kein ViewModel oder sonst was. Einfach das Service welches sich um alles kümmert.
Wenn ich das richtig verstehe kommt würd eich da allerdings auch den "RuntimeListener" reinpacken. Denn so wie ich das sehe ist der auch nur im Lasersystem drinnen.

Gut, dieses Service kann nun völlig unabhängig operieren. Du kannst eine einfach Consoleanwendung schreiben in welcher du die Werte von einem Lasersystem ausgibst, über die Console aber auch Signale senden.
Das Service kümmert sich im idealfal auch gleich darum die Werte in "lesbare" oder wenn man so will in "vernünftige" wert umzuwandeln welche auch gleich im richtigen Datentyp sind.
Also das aus dem String "*S1PF005000#" ein Integer für die kHz wird. Andersrum wenn du was sendest soll sich das Service auch darum kümmern.

Du kannst aber auch wenn du kein Lasersystem zur verfügung hast einen Mock implementieren. Der gibt dann gefakte werte zurück und Simuliert sohin ein Lasersystem. So kannst du Beispielsweise auch Fehlerhafte Werte Simulieren und kannst dann darauf reagieren. sowas mit einer "echten" Maschine zu erzeugen ist oft schwer. Wie einen Fehler herbeiführen der gerade nicht vorhanden ist?

Wenn du das hast, ist 50% getan. Nun nur noch das ganze in einem ViewModel auslesen und verarbeiten. Der User klickt wo drauf und im ViewModel sagst du das nun der Wert xy an die Maschine z gesendet werden soll und alles weitere macht das Service. Je nachdem ob nun der Fake hereingereicht wurde oder die "echte" implementierung wird der neue Wert dann an die Maschine gesendet oder an einen Mock.

Wie genau die das Service erstellst können wir dir hier wenig helfen. Wenn du allerdings die Interface richtig aufsetzt und einen Mock implementierst können wir wieder ins Spiel kommen um dir mit deinem ViewModel zu helfen.
Du wirst aber sehen das sich ein ViewModel dann herrlich einfach und übersichtlich erstellen lässt da du den ganze Boilerplatecode im Service hast. du musst dich um das nicht mehr innerhalb des VM kümmern.

Und da können wir dich dann unterstützen und dir Helfen deine Anwendung komplett MVVM tauglich zu machen, aber beim Service musst du leider selbst wissen was du brauchst. Wir kennen die Maschinen und deren Kommunikation nicht.

Grüße
Sascha

Hutti schrieb:

Ist das in irgend einer Weise negativ für mich, wenn ich es mit Klassen löse?

Ne, das nicht. Ich weis zwar nicht wie du es ohne einem Interface machst das du einen Fake injezierst aber solange es klappt ok. Wenn du ein Interface erstellst hast du ja dann auch eine Klasse. Oder besser zwei Klassen. Eine für den Fake und eine "echte". Beide implementieren das Interface.

Grüße
Sascha