Laden...

wie organisiert man Source Code richtig? (MVVM)

Erstellt von Jimmy99 vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.609 Views
J
Jimmy99 Themenstarter:in
10 Beiträge seit 2011
vor 13 Jahren
wie organisiert man Source Code richtig? (MVVM)

Hi Leute,

habe mich eben in MVVM eingearbeitet und möchte jetzt mein zu unübersichtlich gewordenes Programm umstellen.
Es besteht aus mehreren Usercontrols mit denen Operationen auf mehrere Datenbanken mit Kundendaten gemacht werden.
Bspw. kann man Stammdaten anlegen/ändern/löschen, Rechnungsnummern verwalten, usw.

Die Frage ist jetzt, wie ich den Source Code am Besten organisieren soll,
beim MVVM Konzept trennt man ja nach Model, View und ViewModell - nur ist mir noch nicht so recht klar, was zu Model und was zu ViewModell gehört.
Sollte das Model nur das Datagrid für bspw. Stammdaten Ansicht - oder das gesamte Usercontrol zum Anlegen und Bearbeiten der Stammdaten beinhalten?
Wo sollten sich die Methoden (bspw. speichern, anzeigen usw.) befinden? Im Model oder im ViewModel?

vielen Dank schonmal für Eure Tips...

L
862 Beiträge seit 2006
vor 13 Jahren

Hallo Jimmy99,

Also ins Model gehört sich weder ein DataGrid, UserControl noch sonstige GUI-Elemente. Ins Model kommen lediglich die Daten die du brauchst und sämtliche Methoden die in diesem Context nützlich sind.

Dann brauchst du ein ViewModel, welches als Wrapper um das Model agiert. Dort kapselst du alle Eigenschaften via INotifyPropertyChanged und alle Methoden via Commands.

In die View kommt anschließend die GUI die ViewModels anzeigt und bearbeitet. Sie wird ausschließlich in XAML geschrieben und arbeitet per Bindings mit dem ViewModel zusammen.

Solltest du mit der Basisfunktionalität von WPF nicht auskommen und zusätzliche Funktionen (z.B. Live-Sortierung) benötigen kannst du dir entweder Behaviors schreiben und diese von deiner GUI aus verwenden oder diese Funktionalitäten mit ins ViewModel packen.

J
Jimmy99 Themenstarter:in
10 Beiträge seit 2011
vor 13 Jahren

vielen Dank für die schnelle Antwort,
habe mich etwas missverständlich ausgedrückt,
ich meine natürlich nicht, dass Datagrid und UC in ins Viewmodel sollen, sondern wie Du schon sagst, Daten und Methoden für diesen Context -
Die Frage ist, wie ich die Daten aufteilen soll? für die Daten jedes UC's ein Model oder bspw. für die Daten jedes Datagrid ein eigenes Model?

L
862 Beiträge seit 2006
vor 13 Jahren

Ich würde für diese Überlegung nicht von UserControls aus gehen sondern mir GUI-unabhängig einmal überlegen welche Objekte du in deinem Programm brauchst. Das hat an sich noch nichts mit MVVM zu tun und wird in der Objektorientierung grundsätzlich so gemacht. Wenn dein Programm z.B. die Verkaufszahlen von einem Autohaus verwalten soll würden sich Klassen wie Auto, Verkauf, Verkäufer, Kunde ... anbieten. Dies sind deine Models. Genauso würde man es auch bei einer klassische WinForms-Anwendung oder mit anderen Technologien machen.

Die besonderheit an MVVM ist nun dass du dir für jede dieser Klassen ein ViewModel strickst welches du dann in der GUI verwenden kannst. Wie deine GUI aussieht ist unabhängig von der Anzahl der Models. Wenn du z.B. in mehreren UserControls ein Objekt vom Typ Auto anzeigen möchtest brauchst du die Auto-Klasse nicht X-Mal neu erfinden.

J
Jimmy99 Themenstarter:in
10 Beiträge seit 2011
vor 13 Jahren

ah ok, verstehe,
dann erstelle ich eine Klasse ModelKunde und binde das Datagrid im UserControl Stammdaten an diese Klasse.
Die Methoden, um die Kundendaten aus der DB zu lesen befinden sich im ViewModelKunde.
Und wenn ich irgendwo anders im Programm mal Kundendaten brauche, bspw. eine Anzeige des neuesten Kunden,
dann erstelle ich ein Label, das ich auch an ModelKunde binde und im ViewModel eine neue Methode die den neuesten Kunden zurückgibt.

hab ich das soweit richtig verstanden?

L
862 Beiträge seit 2006
vor 13 Jahren

Nein.

Im Model befinden sich sowohl Methode als auch Daten für den Kunden.

Das ViewModel ist lediglich ein Adapter der es der GUI ermöglicht mit dem Model zu kommunizieren.

Aufgrund deiner Schlussfolgerung habe ich den Eindruck dass dein Verständnissproblem nichts mit MVVM oder WPF zu tun hat sondern dass du noch nicht viel Erfahrung mit der Objektorientierung im Allgemeinen hast. Vielleicht hilft es dir wenn du dir vorerst einmal einige Beispielprojekte dazu anschaust. MVVM ist nichts anderes als eine WPF-komforme Erweiterung des klassischen objektorientierten Architektur. Um MVVM zu verstehen musst du zuerst die Grundsätze der Objektorientierung kennen. Wenn du diese noch nicht verinnerlicht hast würde ich dir vorschlagen dir diese zuerst zu Gemüte zu führen.

J
Jimmy99 Themenstarter:in
10 Beiträge seit 2011
vor 13 Jahren

ok danke, werde ich machen...