MVVM & Entity Framework - Was löst Ereignisse aus?

Question

Ich habe kürzlich eine Datenbanklösung untersucht und bin auf Entity Framework gestoßen. Ich verwende Code First, um Tabellen zu generieren, aber beim Versuch, das Layout meines Codes korrekt zu strukturieren, stieß ich auf ein Problem mit dem Design. Der allgemeine MVVM-Entwurf, dem ich folge, besteht darin, dass sowohl das Modell als auch das ViewModel INotifyProperty erben, so dass die ViewModels darauf hören können, wenn Änderungen an dem Modell vorgenommen werden, an das sie gebunden sind.

Allerdings im Falle einer SQL-Datenbank und EntityFramework. Meine Modelle erben alle im Wesentlichen DbContext und sind POCO-Objekte.

Wenn das Modell keine Möglichkeit mehr hat, Ereignisse auszulösen, können die Ansichtsmodelle die Änderungen nicht mehr hören. Was passiert, wenn ViewModelA eine Änderung an einem Element im Modell (SQL-Datenbank) vornimmt? Wie weiß ViewModelB, dass es sich geändert hat, damit es entsprechend aktualisiert werden kann?

Vielen Dank im Voraus.

Answer 1

Zunächst sollten Ihre "Plain Old CLR-Objekte" (POCOs) nicht von DbContext erben. Mit Entity Framework (Code First) verfügt Ihre Anwendung normalerweise über eine einzelne Klasse, die von DbContext erbt. Diese Klasse enthält im Allgemeinen mehrere DbSet Eigenschaften, die Sammlungen Ihrer POCOs sind.

Zweitens, auch wenn Ihre POCOs von einigen Basisklasse erben, gibt es keinen Grund, sie nicht auch implementieren INotifyPropertyChanged. C# unterstützt keine Mehrfachvererbung, aber es ermöglicht eine Klasse implementieren eine Schnittstelle, auch wenn es auch von einer Basisklasse erbt. Tatsächlich kann eine Klasse von mehreren Schnittstellen erben und von einer Basisklasse erben.

Mit diesen beiden Punkten gibt es keinen Grund, warum Ihre POCOs INotifyPropertyChanged nicht implementieren konnten. Ob das wirklich die beste Architektur ist, ist eine andere Frage, und die Antwort ist ehrlich gesagt ein großes "Es kommt darauf an".

Ich persönlich INotifyPropertyChanged auf POCOs nicht verwenden. Stattdessen verfüge ich normalerweise über Befehle in meinem Ansichtsmodell, die auf Benutzeraktionen reagieren (z. B. auf eine Schaltfläche "Senden" klicken). Diese Befehle ändern häufig nur etwas direkt am selben Ansichtsmodell, aber wenn sie zu einer Änderung des Modells führen, werden sie entweder direkt einige Daten einer Entität oder eines Delegates in eine Klasse ändern, die solche Dinge behandelt (abhängig von der Komplexität der Anwendung). Wenn die Befehle eine Änderung an der Datenbank verursachen, müssen andere Ansichtsmodelle darüber informiert werden. Ich verwende einen Messenger (der ein grundlegendes Merkmal der meisten MVVM-Frameworks ist), um eine Nachricht zu veröffentlichen, die anzeigt, dass sich etwas geändert hat (plus andere nützliche Informationen) Daten, falls erforderlich), und lassen Sie die anderen Ansicht Modelle für die Nachricht registrieren und entsprechend reagieren.