Anwenden von DataAnnotation-Attributen auf ViewModel von Modell

Question

Wir stellen alle unsere DataAnnotations auf unsere Model-Klasse Customer. Wir zeigen dann eine Instanz des Kunden als eine Eigenschaft in unserem zugehörigen ViewModel zusammen mit einigen Nachschlagelisten für Länder usw. an und zeigen dies in unserer Ansicht an. Bis jetzt ist alles gut. Wir lesen dann auf SO und anderen Quellen, dass wir nicht unser gesamtes Kundenmodell-Objekt an die Ansicht übergeben sollten, nur um die Ansicht mit dem Nötigsten zu versorgen, das sie braucht, und noch wichtiger (für uns) zu verhindern Mögliche Probleme bei ModelBinding möglicherweise böswilliger Postbacks, die zusätzliche Informationen hinzufügen, um unsere Modelleigenschaften zu ändern, die andernfalls in der Ansicht nicht verfügbar waren.

Wie erhalten wir all diese DataAnnotation-Attribute vom Modellobjekt und den möglicherweise reduzierten ViewModel-Eigenschaften, ohne das DRY-Prinzip über die Klippe zu werfen?

Sind wir auch richtig in der Annahme, dass wir TryUpdateModel nicht für eine Entität verwenden sollten, die wir aus der db ziehen? Ich denke, unsere Wahl ist, entweder TryUpdateModel zu verwenden und eine Ausschlussliste von Eigenschaften zu übergeben, die mir nicht besonders elegant erscheint, da die Liste nur ein Parameter vom Typ String ist. Oder vielleicht sollten wir TryUpdateModel abschaffen und ein Tool wie AutoMapper verwenden, das typsicherer ist?

Vielen Dank für Ihre Gedanken zu diesen Themen.

Answer 1

Wie erhalten wir all diese DataAnnotation-Attribute vom Modellobjekt und den möglicherweise reduzierten ViewModel-Eigenschaften, ohne das DRY-Prinzip über die Klippe zu werfen?

Sie können nicht. Es ist der Preis zu zahlen, aber ich denke, es ist ziemlich billig, weil in der Tat in dieser abgespeckten Version die Validierungsattribute unterschiedlich sein können und Sie möglicherweise verschiedene Validierungseigenschaften entsprechend den Anforderungen der Ansicht haben. Nehmen wir ein Beispiel: New und Edit Ansicht. In der Ansicht Edit wird die Id der Entität benötigt, während die New Ansicht nicht erforderlich ist, da sie vom Datenspeicher zugewiesen wird (tatsächlich ist in Ihrem neuen Modell möglicherweise keine Id-Eigenschaft vorhanden).

Außerdem platziere ich im Allgemeinen die Validierungsattribute nur auf das Ansichtsmodell, aber dies ist möglicherweise nicht der beste Ansatz. Wenn Sie Ihre Modelle in verschiedenen Anwendungen wiederverwenden möchten, wird es keine Validierungslogik geben.

Sind wir auch richtig in der Annahme, dass wir TryUpdateModel nicht gegen eine Entität verwenden sollten, die wir aus der db ziehen?

Persönlich verwende ich nie TryUpdateModel. Ich bevorzuge es, ein View-Modell als Controller-Aktionsparameter zu übergeben und den Standard-Modellbinder dazu zu bringen, den Job auszuführen. In diesem Fall benötigen Sie natürlich keine Einschluss- oder Ausschlusseigenschaftenliste, da dieses Ansichtsmodell genau auf die gegebene Ansicht zugeschnitten ist.

Soweit es AutoMapper betrifft, ist es ein Muss-Werkzeug für die Konvertierung zwischen Ihren Modellklassen (die in Ihren Repository-Methode Signaturen erscheinen) und die Ansicht Modelle, die an und aus der Ansicht übergeben werden.

Answer 2

Ich habe festgestellt, dass das Platzieren von Validierungsattributen NUR auf das ViewModel und das Beibehalten des Modellobjekts allein der beste Ansatz war.

Die Ansicht Modelle werden alle Daten, wenn ein Benutzer Beiträge validiert und wenn die Daten gültig sind, in der Business-Schicht übernimmt mit den Daten in der Datenbank das Objektmodell der Erstellung der Benutzer gesendet.

In den Diensten/Business-Schicht-Klassen, Funktionen, die aktualisieren oder hinzufügen, akzeptieren nur die notwendigen Werte für ein Objektmodell (Strings, Ints, etc.), aber nie ein ganzes Objekt. Die Serviceklasse ist verantwortlich für das Erstellen des Objekts.

Indem Sie die Überprüfung auf das Ansichtsmodell stellen, stellen Sie sicher, dass alle Daten, die an Ihre Geschäftslogikebene übergeben werden, gültig sind und Sie Änderungen sicher festschreiben können.