Ist in MVVM jedes ViewModel an nur ein Modell gekoppelt?

Question

In einer MVVM-Implementierung ist jede ViewModel mit nur einer Model gekoppelt?

Ich versuche, das MVVM-Muster in einem Projekt zu implementieren, aber ich habe festgestellt, dass manchmal eine View Informationen aus mehreren Models benötigen.

Zum Beispiel für ein UserProfileView, seine UserProfileViewModel Informationen benötigen von UserAccountModel, UserProfileSettingsModel, UserPostsDataModel usw.

Doch in den meisten Artikeln Ich las über MVVM, das Ansichtsmodell besteht nur auf einem Modell über Injection Abhängigkeit. Der Konstruktor nimmt also nur ein Modell auf.

Wie würde das ViewModel funktionieren, wenn es Informationen von mehreren Models erhalten muss? Oder würde eine solche Situation jemals in MVVM auftreten?

PS: Ich verwende nicht das Prism oder Unity Framework. Ich versuche, ähnliche Muster in ein Projekt, an dem ich arbeite, zu implementieren, das nicht Prism oder Unity verwendet. Deshalb muss ich genau verstehen, wie einige dieser Dinge funktionieren.

Answer 1

In meinem Verständnis des MVVM-Patterns besteht die einzige praktische Anforderung darin, dass die View alle ihre Daten aus den Eigenschaften eines ViewModels bezieht (wahrscheinlich durch einen Bindungsmechanismus). Das ViewModel ist eine Klasse, die Sie speziell für diese Ansicht erstellen, und übernimmt die Verantwortung, sich selbst nach Bedarf aufzufüllen. Sie könnten es sich wie ActiveRecord für die Ansicht vorstellen.

Als solches ist es egal, was Sie innerhalb des ViewModel tun, um die Daten zu erhalten, die seine Eigenschaften zeigen sollten. Sie können es erhalten, indem Sie einige Dienste abfragen, ein oder mehrere Geschäftsentitätsmodelle lesen, es vor Ort generieren oder alle oben genannten. Es ist völlig normal, eine Kombination all dieser Dinge zu benötigen, um eine funktionale Ansicht zu erhalten.

Wie in jedem Präsentationsmuster ist der Punkt nur, um den Prozess der Darstellung einiger Daten auf dem Bildschirm zu trennen, von dem Prozess, um diese Daten zu erhalten. Auf diese Weise können Sie jeden Teil des Prozesses separat testen.

Edit: Hier ist ein kleines, aber hoffentlich vollständiges Beispiel für den Fluss von Abhängigkeiten.

Answer 2

Normalerweise gibt es ein ViewModel pro Modell. Diese ViewModels enthalten die Logik zur Verarbeitung der Modelldaten. Auf der anderen Seite hat jede Ansicht ihr eigenes Sichtmodell. Das heißt also:

class ModelA 
{ 
    bool TestValue{get;set;} 
} 
class ViewModelA<ModelA> 
{ 
    ValueViewModel<bool> TestValue{get; private set;} 

    public ViewModelA(ModelA model) 
    { 
     base.Model = model; 
     this.Initialize(); 
    } 
} 

class ModelB 
{ 
    string Username; 
} 
class ViewModelB<ModelB> 
{ 
    ValueViewModel<string> Username{get; private set;} 

    public ViewModelB(ModelB model) 
    { 
     base.Model = model; 
     this.Initialize(); 
    } 
} 

Dies sind die ViewModels, die die Modelle einkapseln. Die Ansichten haben ihre eigenen Viewmodels:

public ViewModelForExactlyOneView 
{ 
    public ViewModelA{get;set;} 
    public ViewModelB{get;set;} 
} 

Ihre Frage zu beantworten, bezieht sich ViewModel1 auf ViewModelA und ViewModelB. Die View kann daher Daten von ViewModel1.ViewModelA.TestValue bekommen.

Answer 3

Sie können mehrere Modelle in einem Ansichtsmodell verwenden. Der Zweck des Ansichtsmodells besteht darin, die Geschäfts-/Datenschicht (d. H. Das Modell) wegzuspulen.

Wenn jedoch mehr als ein Modell verwendet wird, bedeutet dies normalerweise, dass die Ansicht zu groß ist. Möglicherweise möchten Sie es in Benutzersteuerelemente aufteilen (die über eigene Anzeigemodelle verfügen).

Answer 4

Ein ViewModel kann und verwendet in vielen Fällen mehrere Modelle. Es ist selbst ein "Modell" Ihrer Ansicht.

Betrachten Sie ein Profil-Bildschirm, dass ein Benutzer ihre persönlichen Informationen einschließlich Adresse eingibt. Wenn die Adresse in einer "Adress" -Tabelle und der Rest in einer "Profil" -Tabelle gespeichert ist, verwendet das ViewModel sowohl das Profil- als auch das Adressmodell, um ein vereinheitlichtes ViewModel zu erstellen.

Als jgauffin in seiner Antwort erwähnt, können Sie oft Benutzersteuerelemente verwenden, um eine Eins-zu-eins-Beziehung zu erreichen, aber Sie können auch unnötig Komplexität einführen, indem Sie für diese 100% der Zeit versuchen.

Answer 5

Ich würde sicherstellen, dass Sie den Unterschied zwischen View, Viewmodel und allen anderen Modellklassen verstehen. Das ViewModel ist das Modellobjekt, das mit Daten gefüllt ist, an die die Ansicht gebunden werden kann. Es ist nur vorhanden, um Daten für die Ansicht bereitzustellen, wodurch die ViewModel-Objekteinheit testbar wird und die gesamte Geschäftslogik von der Ansicht getrennt wird. So können Sie Ihre Geschäftslogik vollständig entwickeln, ohne die Ansicht selbst zu verwenden, und die Ansicht ersetzen, indem Sie einfach eine andere Ansicht erstellen und verwenden und eine Bindung an die Eigenschaften des ViewModel-Objekts herstellen.Wenn eine Ansicht beispielsweise mit leeren Textfeldern gefüllt ist, können die Inhalte der Textfelder an verschiedene Eigenschaften des Ansichtsmodells gebunden sein.

Normalerweise sollte es eigentlich nur ein Ansichtsmodell geben. Aber wenn es zu komplex ist, können Sie Subproperties der gebundenen Objekte verwenden, wie beschrieben in Binding to ViewModel.SubClass.Property (sub-property)

Das Ansichtsmodell die Daten bekommen kann aus vielen verschiedenen Quellen zu der Ansicht zurück, Business-Objekte, Datenbanken, was auch immer.

Answer 6

ein viewmodel enthält die "view logic" - so alles, was Sie in der Ansicht anzeigen möchten, wird durch das Viewmodel angezeigt. Wenn Sie Daten von verschiedenen "Modellen" anzeigen möchten, aggregiert Ihr Ansichtsmodell dies und die Ansicht kann sich daran binden.

der Hauptzweck von MVVM war BTW Unit Test. Dies bedeutet einfaches Testen der Ansichtslogik ohne UI.

EDIT: warum:

Ansichtsmodell hat nur einen einzigen Parameter für die Ansicht in seinem Konstruktor

EDIT2:

es btw zwei Ansätze mit mvvm arbeiten "First View" ist "Viewmodel First", Sie können natürlich beide mischen und den besten Ansatz für Ihre Bedürfnisse auswählen.

Answer 7

benutzen Sie einfach das User-Modell in Ihrer Ansicht

public partial class User : Login 
{ 
    public string Password { get; set; } 

    public List<Customer> customer { get; set; } 
} 

in dem die anderen Modell Login geerbt und das Kundenmodell auch in diesem Modell verwendet ..