spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo Leute,

ich hoffe, dass sich jemand trotz des etwas sperrigen Titels hierher verirrt und mir helfen kann. Wenn euch ein besserer Titel einfällt schreibt ihn.

Kleine Beschreibung der Verhältnisse:
Ich bin zurzeit wieder an meiner DMX-Software beschäftigt und habe schon ein paar tausend Zeilen Code C# geschrieben. Meine Klassen, die anfangs nur die grundlegende Funktionalität von Effekten und Geräten darstellten sind inzwischen sehr groß geworden. An der grundlegenden Funktionalität (Farbenmischen, Verknüpfen von Effekten mit Fadern oder die Ausgabe über den DMX Bus) der Klassen hat sich nicht viel geändert und dieser Teil ist recht kompakt.

Der restliche Code der Klassen stellt Funktionen bereit, die zu einem großen Teil die GUI betreffen: z.B. Farbe von Fadern, Anzeigenamen oder IDs. Die Hauptaufgabe besteht darin diese Werte zu speichern und mittels INotifyPropertyChanged der GUI eine Änderung rückzumelden. Weiterhin müssen diese Werte an bestimmte Member dieser Klassen übergeben werden, damit diese die Werte auch visualisieren können.

Fragestellung:
Nun kommt immer mehr "Schnickschnack" dazu und ich frage mich, ob diese GUI-spezifischen Funktionen in diese Klassen hineingehören. Ich habe schon überlegt, wie ich das auslagern kann, gerade weil viele Funktionen in mehreren Klassen eingesetzt werden. Leider können C#-Klassen nicht von mehreren Basisklassen erben, sondern nur von einer. Meine Idee für jede Funktionalität eine Basisklasse zu schreiben ist also sinnlos.

Meine Versuche das Problem zu lösen:
Bisher habe ich mir mit Interfaces beholfen, die wenigstens die Variablennamen auslagern und so eine gewisse Struktur schaffen. So kann ich recht schnell erkennen, ob eine Funktionen zur "Grundklasse" oder zu einer GUI-spezifischen Erweiterung gehört. Leider kann ich den Code aber nicht auskoppeln um meinen Klassencode zu kürzen.

Ich hoffe, dass ihr meine Überlegungen nachvollziehen könnt. Code ist bei dieser Designfrage denke ich unnötig. Gibt es vielleicht ein Pattern, dass diesem Problem in C# begegnet? MVVM kenne ich, allerdings weiß ich nicht ob diese Erweiterungsfunktionen da hinein gehören und wie ich das anstellen soll.

Schonmal Danke für eure Antworten!

Das war die schlimmste Antwort mit der ich gerechnet habe! Dann muss ich wohl nochmal was zu MVVM fragen:

- Speichert ein ViewModel irgendwelche Daten des Models oder etwas anderes? Speichert es das Model selbst? Oder ist es ein reiner Wrapper um ein Model?
- Darf ein Model NUR über sein ViewModel geändert werden? Oder wie bekommt die GUI Änderungen mit, die der Grundlegende-Code im Model verursacht?
- Wird ein ViewModel-Objekt pro View oder pro Model erzeugt? Und kennen sich alle drei gegenseitig oder gibts da eine Hierarchie?

Vielleicht habe ich ja jetzt MVVM besser verstanden. Einige Fragen habe ich dennoch. Ich mache mal ein Beispiel: Man hat eine Geräteklasse, die hat mehrere Objekte einer Funktionsklasse (RGB, Dimmer, Pan/Tilt) und diese wiederum haben jeweils ein Objekt der Pin-Klasse, damit sie sich an Effekte anschließen lassen. (Wie eine LED an einen IC - So habe ich das zurzeit aufgebaut) Die Objekte dieser Klassen kennen sich gegenseitig und modifizieren sich über Methoden oder direkt die Member. Keine dieser Klassen implementiert INotifyPropertyChanged.

Alle diese Objekte sollen darstellbar und über eine GUI modifizierbar sein. Muss nun jedes Model ein eigenes ViewModel bekommen? Und den Objekten bringt es doch nichts mehr, wenn sie sich gegenseitig kennen - schließlich dürfen sie doch eh nur über das jeweilige ViewModel auf das Objekt zugreifen? Jetzt habe ich doch zwei Möglichkeiten, wie ein Model ein anderes modifiziert:

- Ein Geräte-Model speichert die ViewModels aller seiner Funktions-Model und ruft dann die Funktionen der ViewModels auf.
- Ein Geräte-Model speichert die Models aller seiner Funktions-Model. Diese Models haben ihre ViewModels als public-Member gespeichert. Möchte nun das Gerät ein Funktions-Model verändern, dann schnappt es sich das richtige Model, nimmt die ViewModel-Eigenschaft von ihm und ruft da die Modifikationsroutinen auf.

Ich hoffe, ich konnte meine Frage verständlich vormulieren.

Zitat von »BlueCobold«

Dass sich Models gegenseitig in die Methoden und gar Member greifen, ist auch nicht gut. Hierarchisch kann das schon Sinn machen, aber niemals gegenseitige Abhängigkeit verwenden.

Und wie sollen dann meine Objekte (Models) miteinander kommunizieren, sodass die GUI das Ganze auch mitbekommt?

Nein, mein CodeBehind ist sehr leer... Ich mache ziemlich viel mit XAML-Code, Datenbindung und DataTemplates. Oder ist das auch nicht korrekt? Hab nix dagegen, wenn ich noch was vor mir habe - nur find ichs doof, wenn ich nicht weiß WAS ich noch vor mir habe und WIE ich den Berg abbauen kann. Ich werde mal nach Tutorials schauen. Habt ihr gute Vorschläge? Mit möglichst wenig Akzent im Englischen.

Soo kleines Update:

Ich habe mir folgendes Tutorial angeschaut: https://www.youtube.com/watch?v=EpGvqVtSYjs

Nun bin ich der Meinung, das MVVM garnicht das richtige Pattern für meine Anwendung ist. So wie ich das verstanden habe ist das Hauptziel von MVVM, dass ich ein Datensatz (Model) über eine GUI (View) anzeigen und verändern kann. Dabei kann die View beliebig angepasst werden.

Warum ich finde, dass das nicht zu meiner Anwendung passt: Bei mir ist Primärziel, dass die Objekte möglichst realitätsgetreu eine Steuerung von DMX-Geräten über Effekte darstellt. Darum gibt es auch eine Hierarchie zwischen den Klassen und sie können sich gegenseitig über Methoden und Eigenschaften modifizieren. Danach geht es mir erst um die Visualisierung: (Fast) alle Objekte sollen anzeigbar sein, um Parameter vom User verändern zu lassen und um dem User Einsicht in die aktuellen Werte, mit denen gerechnet wird zu geben. Meine Anwendung stellt also keine Datensätze wie Telefonbücher oder Kundentabellen dar, sondern soll ein dynamisches System anzeigen, das erstmal ohne den Benutzer funktioniert.

Ich hoffe ihr versteht den Unterschied, den ich ausdrücken möchte. Falls das Tutorial den falschen Eindruck von MVVM in mir geweckt hat, schickt mir doch bitte einen besseren Link. Ansonsten: Gibts ein besseres Pattern für meinen Anwendungsfall?