2014-01-20 10 views
10

Ich habe in dem Geschäftsmodell Product und Category wie unter dem Namen füge ich die Validierungen:Was sollte in meinen View Models sein?

public class Product 
{ 
    public int ProductId {get; set;} 
    [Required] 
    [StringLength(25)] 
    public string Name {get; set;} 
    public string Description {get; set;} 
    public int CategoryId {get; set;} 
} 

public class Category 
{ 
    public int CategoryId {get; set;} 
    public string Name {get; set;} 
} 

Für die Ansicht Modell, das ich so etwas wie diese erstellt habe:

public class ProductViewModel 
{ 
    public Product Product {get; set;} 
    public IList<Category> Categories {get; set;} 
} 

Ein Freund von mir halten vorgeschlagen Alle Validierungen im View-Modell und das Zuordnen aller Eigenschaften des Business-Modells im View-Modell wie folgt:

public class ProductViewModel 
{ 
    public int ProductId {get; set;} 
    [Required] 
    [StringLength(25)] 
    public string Name {get; set;} 
    public string Description {get; set;} 
    public int CategoryId {get; set;} 
    public IList<SelectListItem> CategoryDropdownValues {get; set;} 
} 

Ich fragte ihn die Vorteile dieses Ansatzes zu dem oben genannten, er war nicht sehr sicher. Er bestand jedoch darauf, dass Sie die Geschäftsmodelle nicht direkt in Ihren Ansichten verwenden sollten und dass nur die Modelle validiert werden sollten.

Meine Fragen:

  • Sollte ich im Hinblick auf Modelle oder Geschäftsmodelle meine Validierungslogik halten?
  • Ist es schlecht, wenn die Ansichtsmodelle von Geschäftsmodellen abhängen?

Antwort

3

Ihr Freund hat Recht. Ihre Fragen

  1. Es gibt Benutzereingangsvalidierung und Geschäftsregelvalidierung. In den meisten Fällen ist die Eingabevalidierung Teil der Validierung von Geschäftsregeln, in asp.net mvc führt das Framework diese Validierung jedoch automatisch aus. Um Doppelungen zu vermeiden, bedeutet dies, dass die UI-Validierung die Geschäftsvalidierung verwenden sollte. Dies kann leicht mit FluentValidations durchgeführt werden (Datenanmerkungen sind zu starr IMO).

    In diesem Fall erfolgt die UI-Vlaidation auf UI-Ebene mithilfe der Validierung des Geschäftsmodells.

  2. Ansicht Modelle sind immer abhängig vom Geschäftsmodell zumindest zu einem gewissen Grad, aber es gibt nicht dasselbe. Sie sind verschiedene Modelle mit unterschiedlichen Zwecken, so dass sie getrennt gehalten werden sollten. Die Tatsache, dass Ihr View-Modell wahrscheinlich zu 90% mit dem Business-Modell (also Datenstrukturen) identisch ist, ist nur ein Zufall. Wir wollen jedes Modell in seiner eigenen Schicht behalten und es passiert einfach, dass sie die gleichen Eigenschaften haben.

0

Halten Sie die Validierung auf der niedrigsten Ebene wie möglich, das sind die Klassen. So überprüft MVC die Validierungen automatisch.

+0

Niedrigste? Wie im Geschäftsmodell oder View-Modell? –

+0

Geschäftsmodell. – iefpw

2

Ich würde die Validierung im View-Modell behalten. Von dort bezieht MVC seine Metadaten. Validierungsattribute werden auch in MVC-Assemblys definiert. Sie möchten Ihrer Geschäftslogik oder etwas anderem als der Benutzeroberfläche keine MVC-Abhängigkeit hinzufügen. UI-Modelle können vom Geschäftsmodell abhängen, aber nicht umgekehrt. Ich schlage auch vor, dass Sie einige Best Practices Artikel lesen, wie diesen: http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx

+0

Mein Anliegen ist, wenn ich dieselben Geschäftsmodelle für eine andere Benutzeroberfläche wiederverwenden möchte, sagen wir Mobile App, muss ich für diese Benutzeroberfläche erneut Validierungen hinzufügen, richtig? –

+0

@RatSalad Genau deshalb sollten Sie diese Validierung nicht auf Präsentationsebene beibehalten, wenn dies möglich ist. Was seltsam ist, ist, dass der verlinkte Artikel deutlich zum Ausdruck bringt, dass alle Validierungslogik in das Modell eingefügt wird. – rae1

3

Die Validierung sollte auf Domänen-/Unternehmensebene erfolgen. Andernfalls werden Sie die Validierungsregeln in der gesamten Anwendung duplizieren. Dies ist der kleinste gemeinsame Nenner, mit dem alle Service- und Präsentationsebenen interagieren.

Die Verwendung von Domänenmodellen in einer Präsentationsansicht ist ein anderes Problem, mit Vor- und Nachteilen.In Ihrem speziellen Fall kann das Umschließen Ihrer Modelle mit einem ansichtsspezifischen Ansichtsmodell einige der auftretenden Duplikationen mindern. Achten Sie jedoch darauf, dass Sie Modelle nicht innerhalb von Ansichtsmodellen genau so "ablegen", wie sie benötigt werden. Dies führt schnell zu Leistungseinbußen, da viele unnötige Informationen geladen werden.

Das ASP.NET MVC-Framework analysiert und validiert korrekt Attribute aus der System.ComponentModel.DataAnnotations namespace. Sie können diese verwenden, um Ihre Domänenmodelle zu kommentieren, und bei Bedarf können Sie Ihre Ansichtsmodellpräsentation bei Bedarf erweitern, indem Sie Komponenten verwenden, die auf das MVC-Framework beschränkt sind.

2

Im Allgemeinen sollte Ihre Benutzeroberfläche auf Ansichtsmodelle verweisen und Ihre Ansichtsmodelle sollten eine Hülle um Ihre Modelle sein. Die Aufgabe des Modells besteht darin, Ihr Geschäftsobjekt zu modellieren. Aufgabe des Ansichtsmodells ist es, diese Informationen so anzupassen, dass sie in einer Benutzeroberfläche dargestellt werden können.

In der Codebasis, an der ich arbeite, haben wir diese Abkürzung viele Male für einfache Modelle genommen. Wenn sich der Code jedoch weiterentwickelt, müssen Sie der Benutzeroberfläche neue Funktionen hinzufügen, die für das eigentliche Modell nicht sinnvoll sind. Wenn Sie dieses Ansichtsmodell nicht jetzt hinzufügen, wird ein naive Programmierer sicherlich später kommen und die UI-Bits direkt zum Modell hinzufügen.

Für die Validierungen stimme ich zu, dass Sie wahrscheinlich das auf dem Modell selbst wollen; Das bedeutet, dass das Modell immer validiert wird, unabhängig davon, wo es angezeigt wird.

Aber es kann Fälle geben, in denen Validierungen auf dem Ansichtsmodell sein sollten: Stellen Sie sich ein Ansichtsmodell vor, das eine Liste von Produkten anzeigt, und ein Filterfeld enthält, so dass Sie die Liste der gesuchten Elemente eingrenzen können. Wenn der Filter beispielsweise keine Zeichen "&" enthalten darf, wird diese Validierung auf das Ansichtsmodell und nicht auf das Modell angewendet.

1
  • Validierung sollte in Ihrem Business Layer
  • durchgeführt werden Sie das Geschäftsmodell direkt auf Ihrem UI

Also nicht aussetzen, wie validieren Sie die Eingabe in der Benutzeroberfläche dann? -Ja, Sie müssen die Validierung zu einem gewissen Grad mit den DataAnnotations-Attributen in Ihren MVC-View-Modellen duplizieren. Ich denke, das passt besser zu SRP, da es nicht dasselbe ist, um Web-Eingabe zu validieren und Geschäftsregeln zu validieren.

Verwandte Themen