Bewährte Verfahren zur Vermeidung von Doppelvalidierungslogik, wenn mit beiden Domänenobjekten und Ansicht Modelle in ASP.NET MVC

Question

gängiges Szenario arbeiten:

Hierarchisch Domain-Modell ist für Präsentationszwecke zu flache Ansicht Modell abgebildet werden.

Ich habe ein komplettes Validierungssetup in meiner Domäne und möchte das Mapping des Ansichtsmodells zum Domänenobjekt vermeiden, nur um herauszufinden, dass eine Eigenschaft ungültig ist. Ich möchte auch nicht meine Validierungslogik in meinen View-Modellen duplizieren.

Was sind einige gute Praktiken hier?

Ich bin gegen Schnittstellen sowohl für Ansichtsmodelle als auch für Domänenobjekte, da Ansichtsmodelle normalerweise streifig und flach sind, während Domänenobjekte oft verschachtelt sind und viele andere Datentypen für Eigenschaften haben.

Ich denke über einen Pluggable-Validator nach, der schlau genug sein wird, um sowohl Domain-Objekte als auch View-Modelle zu validieren, aber ein wenig skeptisch bezüglich der Implementierung.

Aber der Einfachheit halber ich bin Neigung zu diesem Ansatz:

Server-seitige Validierung nur in Domänenmodell geschieht; Ansichtsmodelle werden nicht validiert, aber Daten werden auf dem Client mit JavaScript validiert. In den meisten Fällen sind meine Ansichtsmodelle gültig und die Validierungslogik bleibt an einem Ort und wird nur im Domänenmodell auftreten. Dieser Ansatz hat den Nachteil, dass die asp.net mvc 2-Validierung dies nicht unterstützen kann. Was denkst du?

Danke.

Answer 1

Die Microsoft Enterprise Library bietet eine solche "Pluggable Validation" -Bibliothek, die auf Generics basiert, wenn Speicher dient.

Ich mochte nicht die Art, wie es funktionierte, ganz zu schweigen von der Anzahl der Abhängigkeiten von anderen EL-Komponenten, aber es könnte immer noch einen Blick wert sein.

Ich bin auf keinen Fall ein Experte in diesem Bereich, aber ich bin der festen Überzeugung, dass Daten überprüft werden sollten, bevor Sie etwas damit tun und IMMER, bevor Sie zu Ihrem Repository zu committen. Daher ist der beste Platz für Ihre Validierungslogik Ihr Business Logic Layer. Client-seitige Validierung, obwohl für den Benutzer angenehm, macht die Code-Pflege zu einem Albtraum und führt auch zu Code-Duplizierung, die später Probleme verursachen kann.

Ihre Präsentationsobjekte sollten meiner Meinung nach DTOs sein.Wenn ein Benutzer Daten an Ihre Controller (und BLL) zurückgibt, können Sie die Präsentationsobjekte mithilfe von Parsern in Geschäftsobjekte umwandeln, die dann validiert werden können.

Ich empfehle, lesen Sie Rudy Lacovara Blog (aka The Angry .NET Developer). Er ist ein sehr bescheidener Kerl mit vielen guten Sachen, die man zu solchen Sachen sagen kann.

HTH

Answer 2

There is no validation approach that fits always.

In Ihrem Fall würde ich die Validierung von mvc2 (mit Client-Validierung) verwenden und auf die Domänenvalidierung zurückgreifen, wenn die Validierung des Viewmodells erfolgreich ist.

Answer 3

Ich mag die Idee von Pluggable/injizierbaren Validatoren. Dies ist, wie ich in der Regel über Validierung gehe (egal, ob es Webformulare, Mvc, Wpf, etc ... ist). Warum? Weil die Validierungsregeln sich je nach Szenario und Anwendungsebene unterscheiden. Beispiel: Ihr Ansichtsmodell weist möglicherweise bestimmte Validierungsregeln auf, die auf das UI-Layout und nicht auf Domänen- oder Infrastrukturregeln zurückzuführen sind. Wenn Sie die Regeln und Validatoren zusammensetzbar machen, können Sie viele der Dateneinschränkungsregeln in jeder Ebene/jedem Szenario wiederverwenden.

Obwohl ich denke, dass Javascript-Validierung Dinge für den Benutzer bissig macht, wäre ich misely von nur mit Javascript in der VM.