MVC Verwenden von Domänenmodellen in Ansichtsmodellen

Question

Ist das folgende OK zu tun? Ich weiß, dass Domänenmodelle niemals in Ansichten verwendet werden sollten, aber ist es in Ordnung, Domänenmodelle in Ihren Ansichtsmodellen zu verwenden? Bei einigen sehr kleinen Modellen scheint es nicht sinnvoll, ein View Model für sie zu erstellen und zu verwalten.

Für Beispiel

public class LoginDomainModel 
{ 
    public string Email { get; set; } 
    public string Password { get; set; } 
    public string DisplayName { get; set; } 
    public long UserTypeID { get; set; }  
    public virtual UserType UserType { get; set; } 
} 
public class UserTypeDomainModel 
{ 
    public UserType() 
    { 
     this.Logins = new List<Login>(); 
    } 
    public long UserTypeID { get; set; } 
    public string UserType { get; set; } 
    public string Description { get; set; } 
    public virtual ICollection<Login> Logins { get; set; } 
} 

public class LoginViewModel 
{ 
    public string Email { get; set; } 
    public long UserTypeID {get; set;} 

    //Right here 
    public List<UserTypeDomainModel> UserTypesSelectList {get; set;} 
} 

Answer 1

Ich persönlich verwende Domain-Modelle in der Ansicht wenn sie natürlich eine genaue Passform seien. Dies ist wahrscheinlich nur bei trivialen Projekten der Fall, bei denen es sich um CRUD-Elemente handelt (Bearbeitung der Domain-Entitäten auf einfache Weise). Ich finde es eine Zeitverschwendung, aus Gründen der Reinheit eine exakte Kopie einer Domäneneinheit zu erstellen.

Ich werde nie ein Domänenmodell im geringsten zu ändern, um Bedürfnisse der Ansicht zu berücksichtigen. In 95% meiner Projekte ist dies der Umstand, in dem ich mich befinde. In dem Moment, in dem Sie die Domäne wegen der Aussicht verschmutzen, verursachen Sie Probleme mit der Wartbarkeit.

Answer 2

Ich habe lange mit der wahrgenommenen Duplizierung durch separate View-Modelle und Domain-Modelle gekämpft. Ich würde behaupten, da sie für verschiedene Zwecke gedacht sind, ist es nicht wirklich Duplikation, aber es fühlt sich immer noch "falsch", so viele ähnliche Eigenschaften zu deklarieren.

In sehr kleinen Projekten (vor allem solche mit einer vertrauenswürdigen Gruppe von authentifizierten Benutzern) kann ich direkt an die Domänenmodelle binden und damit fertig werden. Oder ich mische und match, wenn das Ansichtsmodell eine andere Struktur benötigt (wie @Eric J. beschreibt).

Jedoch: Der ModelBinder versucht, die Werte in der Anforderung an die Eigenschaften in Ihrem Modell anzupassen. Dies bedeutet, dass jede Eigenschaft in Ihrem Domänenmodell potenziell von einer (Rogue) -Anforderung ausgefüllt werden kann. Es gibt Möglichkeiten, dies zu verhindern, aber für mich überwiegt die innere Ruhe ein wenig mehr Aufwand, separate Ansichtsmodelle zu erstellen.

Ich sehe keine absolute Notwendigkeit, ein separates Ansichtsmodell für schreibgeschützte, ungebundene Werte (möglicherweise die Liste der Benutzertypen in Ihrem Fall, obwohl public virtual ICollection<Login> Logins kann dies negieren) zu erstellen.

Alternativ können Sie das Domänenmodell auf eine UI-orientierte Abstraktion projizieren (z. B. IEnumerable<SelectListItem>). Sie können SelectListItems für eine Vielzahl von Eingabemechanismen verwenden, sodass Sie sich nicht an ein bestimmtes Benutzeroberflächenverhalten binden.

Auch mit Abstraktion müssen Sie möglicherweise noch überprüfen, dass die Anforderung keinen ungültigen Wert enthält. Zum Beispiel können vielleicht nur Super Admins bestimmte UserTypeDomainModel IDs zuweisen. Unabhängig von der Abstraktion müssen Sie dies noch überprüfen.

TLDR: abstrakte Domain-Modelle so viel wie praktisch ist, finden geeignete Abstraktionen (ein neues Ansichtsmodell ist nicht immer die richtige Antwort), und sein (leicht paranoid) über die Eingabe-Validierung.

Answer 3

Es hängt davon ab, was Sie unter "Domain-Modell" verstehen. Meinst du EF-Einheiten? Oder meinst du Business-Layer-Objekte?

Es ist nie eine gute Idee, EF-Entitäten an die Ansicht zu übergeben, insbesondere wenn Sie die Standardmodellbindung verwenden. Dies kann Sicherheitsprobleme verursachen, wenn Sie nicht vorsichtig sind. Die gleichen Probleme können jedoch auftreten, wenn Sie nicht mit Geschäftsobjekten vorsichtig sind, die an die Ansicht übergeben werden.

Einer der großen Vorteile von View-Modellen besteht darin, dass Sie das Mapping von Daten viel genauer steuern können, sodass Sie einfacher validieren können, dass nur die korrekten Maps auftreten.

Es kommt alles auf Ihre App obwohl. Wenn es sich um eine einfache App handelt, lohnt es sich möglicherweise nicht, komplexe Zuordnungen zu erstellen. Wenn es eine komplexe App ist, muss diese für eine lange Zeit leben, und wird wahrscheinlich viel aktualisiert werden .. dann sollten Sie definitiv die Mühe investieren.