MVVM in Verbindung mit der 3 Schichten-Architektur

Hallo zusammen,

mich würde mal interessieren, wie/ob ihr MVVM in Verbindung mit der 3 Schichten-Architektur implementiert. Speziell geht es um VM und BL, da die beiden sich ein wenig überschneiden.

Greift ihr aus dem Viewmodel direkt auf einen DAL zu, oder habt ihr noch einen BL dazwischen?

Ich habe zum Testen und weil ich es für richtig halte die BL schicht gelassen und die komplette Verarbeitung von Daten in diese Schicht gepackt und das ViewModel kümmert sich nur um Eingaben oder ähnliches. Jetzt bin ich mir aber ehrlich gesagt nicht sicher wie ich dann zum Beispiel das bearbeiten meiner Objeke angehen soll.

Heißt:

ViewModel mit einer Observablecollection<Item>
BL mit einer List<item>
DAL gibt einer List<item> aus einer Datenbank/XML Datei oder was auch immer zurück

Z.B.

Wenn ich meiner Liste jetzt noch ein Item hinzufügen möchte, benutze ich direkt die Obscollection, oder die List<item> im Bl und schmeiße dann ein Event mit der aktualisierten Liste für mein Viewmodel.

Ich hoffe ihr versteht worauf ich hinaus möchte und könntet mir erklären, wir ihr so etwas angeht.

Danke

Hallo Rioma,

Grundsätzlich ist deine 3-Schichten-Beschreibung okay. Man kann aber das VM auch "nur" als Fassade benutzen und deine Servies und/oder Provider anbieten (wie eine Fassade eben) und dann auf die Properties binden.

Du kannst auch direkt mit den Repos (DAL) im VM arbeiten, je nach Grösse und Architektur.

Aktionen sollten immer in Commands ausgeführt werden (eigene Klasse!), die im VM nur angeboten werden. Da kannst du dir deine Servies injecten (per DI). Danach das INotifyPropertyChanged vom Service aus zu schmeissen ist völlig okay.

Gruss

Coffeebean

Hallo und danke erstmal für deine Antwort.

Wenn ich dich richtig verstanden habe wäre dieses vorgehen Ok:

1.User klick auf Button und will Item hinzufügen\löschen\bearbeiten
2.VM reagiert auf Command, erzeugt\verändert objekt und übergibt es dem BL
3.BL aktualisiert seine Liste und übergibt die aktualisierte Liste dem VM per Event zurück
4.VM bekommt dadurch eine neue\aktualisierte Obsvcollection und die GUI wird aktualisiert

Sorry für die doppelte Frage, mir kommt das alles so ein bisschen wie 3 mal im Kreis und hinten durch die Brust ins Auge vor .... 😄

Ich habe das unter anderem deswegen so gemacht, weil ich es sehr unschön fand auf einer Obsvcollection zu Arbeiten und beim speichern sie nach ganz unten durchzureichen.

Hallo Rioma,

das einzige Event, was du brauchst, ist INotifyPropertyChanged.

Das VM bietet das Command nur an. Das Command würde über den Service das Item in der DB oder wo auch immer hinzufügen. Danach schmeisst du nur ein INotifyPropertyChanged auf dem Property, auf dem die Liste gebunden ist. Wenn das im VM ist, schmeisst dus über das Command (public Methode im VM beispielsweise) oder, wenn die Liste auf nem Service hängt, schmeisst dus gleich da.

Gruss

Coffeebean

Vielen Dank für die Hilfe

Du schreibst ja das VM bietet das Command nur an und die Logik steckt dann im BL.
Das heißt das Command würde dann direkt auf einer Methode aus dem Service hängen.

Bisher habe ich es so gemacht:

User gibt was in Textbox ein --> Textbox hängt an Property in dem VM
Benutzer möchte speichern --> Command ruft Methode im VM auf
Im VM lese ich die Property aus, erzeuge das Objekt und übergebe es an den BL

Ich wüsste leider nicht, wie ich an die Eingaben komme, wenn ich das Command direkt an den Service hänge.

Habe ich deine Aussage falsch verstanden?

Gruß
Rioma

EDIT:

Ich nehme an, du hast die das ganze so gedacht (aus deinem Blog):

	<TextBlock Text="{Binding NameProvider.NameToDisplay}"></TextBlock>

In meinem Fall wäre dann NameProvider mein BAL und ich hätte im VM keine Logik mehr.
Nur wie wäre es dann mit meiner ObservCollection? Geht die mit in den BL oder bleibt diese im VM?

Hallo Rioma,

Nur wie wäre es dann mit meiner ObservCollection? Geht die mit in den BL oder bleibt diese im VM?

das in meinem Blog ist nur eine Lösung, wenn man das ViewModel etwas schlanker halten will. Deine ObservableCollection hängt da, wo du sie anbietest. im VM, wenn das okay ist. Willst du sie lieber woanders haben, dann wandert sie u.U. auch auf irgendwas, was du auf dem VM anbietest. Das kommt immer drauf an.

Benutzer möchte speichern --> Command ruft Methode im VM auf
Im VM lese ich die Property aus, erzeuge das Objekt und übergebe es an den BL

Das Command wird über das VM angeboten, ist eine eigene Klasse und kann, wenn du das so machen willst und schon eine BL hast, irgendeinen Service antriggern, der dir das Gewünschte abspeichert. Den "Umweg" übers Viewmodel finde ich persönlich nicht sinnvoll. Mitgeben kannst du INfos auch über den CommandParameter.

Danach schmeisst das Command ein Update durch beispielsweise eine Methode auf dem ViewModel. Oder du gibst das ViewModel gleich mit ins Command und schmeisst das INotifyPropChanged direkt.

Gruss

Coffeebean