In einem ASP.NET MVC-Projekt verwenden wir AutoMapper, um vom Domänenmodell zum Viewmodell zu mappen - und dabei manchmal auch eine Hierarchie einzuebnen. Das funktioniert wie ein Zauber und macht die Rendering-Logik unserer Ansichten sehr schlank und einfach.
Die Verwirrung beginnt, wenn wir den umgekehrten Weg vom Viewmodel (oder Postmodel oder Editmodel) zum Domänenmodell, gehen wollen, insbesondere beim Aktualisieren von Objekten . Wir können das automatisierte / wechselseitige Mapping nicht verwenden, weil:
ChangeManagerForEmployee() " oder ähnliches aufrufen. Dies wird auch in Jimmy Bogards Artikel beschrieben: Der Fall für Zweiwege Mapping in AutoMapper , aber die Lösung dafür wird nicht im Detail beschrieben, nur dass sie gehen:
Von EditModel zu CommandMessages - geht von der losen Eingabe aus EditModel zu stark typisierten, ausgebrochenen Nachrichten. Ein einzelnes EditModel könnte ein halbes Dutzend Nachrichten generieren.
In einer ähnlichen SO-Frage gibt es eine Antwort von Mark Seeman wo er das erwähnt
Wir verwenden abstrakte Mapper und Dienste, um ein PostModel einem Domain-Objekt zuzuordnen
aber die Details - die konzeptionelle und technische Umsetzung - werden weggelassen.
Unsere Idee ist jetzt:
UpdateModel()
Kann jemand einige Beispiele dafür angeben, wie sie von FormCollection über editmodel / postmodel zum Domänenmodell kommen? "CommandMessages" oder "abstrakte Mapper und Services"?
Sie könnten CQRS (Command Query Responsibility Segregation - ich denke, dies könnte das Konzept sein, das Ihnen fehlte) überlegen, möglicherweise sogar mit Event Sourcing.
Es ist im Grunde eine Praxis, die Logik des Lesens von einer Datenquelle zu trennen und in eine Datenquelle zu schreiben, könnte sogar bedeuten, unterschiedliche Datenmodelle zum Lesen und Schreiben zu haben.
Dies könnte ein guter Anfang sein: Ссылка
Option C: Setzen Sie alles in die Controller-Aktion. Als nächstes, wenn das haarig wird, zerlegen Sie sich in Dienste (abstrakte Mapper) oder Nachrichten als Methoden (die Befehlsnachricht Weg).
Befehlsmeldung:
%Vor%Und der Prozessor:
%Vor%Es geht wirklich nur darum, die "Verarbeitung" des Formulars aus der Controller-Aktion in einzelne spezialisierte Handler zu verschieben.
Aber ich würde diesen Weg nur wirklich gehen, wenn Controller-Aktionen haarig werden. Andernfalls nehmen Sie einfach das Formular und führen Sie die erforderlichen Aktualisierungen für die Domänenmodelle nach Bedarf durch.
Es gibt einige Ähnlichkeiten mit dem, was ich gemacht habe. Meine Hierarchie von Ansichtsmodellen ist nur etwas abgeflacht von seinen Domänenobjekt-Äquivalenten, aber ich muss mit dem Aufruf von expliziten Dienstmethoden beim Speichern umgehen, um z. B. Hinzufügen zu untergeordneten Sammlungen, Ändern wichtiger Werte usw., anstatt einfach das Mapping umzukehren. Ich muss auch vorher und nachher Snapshots vergleichen.
Mein Speichern ist Ajax, das als JSON zu einer MVC-Aktion gepostet wird und diese Aktion magisch durch MVC an eine Ansichtsmodellstruktur gebunden zurückgibt. Ich verwende dann AutoMapper, um das Top-Level-View-Modell und seine Nachkommen in die entsprechende Domänenstruktur zu transformieren. Ich habe eine Reihe von benutzerdefinierten AutoMapper ITypeConverters für die Fälle definiert, in denen ein neues untergeordnetes Element auf dem Client hinzugefügt wurde (ich verwende Knockout.js) und ich muss eine explizite Service-Methode aufrufen. Etwas wie:
%Vor%Ich mache eine ähnliche Sache für Löschungen und dieser Prozess fällt ziemlich gut durch die gesamte Struktur. Ich nehme an, eine abgeflachte Struktur könnte entweder einfacher zu bearbeiten sein oder härter - ich habe ein AbstractDomainViewModel mit einer ID, mit der ich das obige Matching mache, was hilft.
Ich muss Vergleiche vor und nach der Aktualisierung durchführen, weil meine Service-Schicht eine Validierung auslöst, die andere Teile des Objektgraphen beeinflussen kann, und dies legt fest, was JSON als Ajax-Antwort zurückgeben muss. Ich interessiere mich nur für Änderungen, die für die Benutzeroberfläche relevant sind. Daher transformiere ich das gespeicherte Domänenobjekt zurück in ein neues Ansichtsmodell und verwende dann eine Hilfsmethode zum Vergleichen der beiden Ansichtsmodelle mithilfe einer Kombination aus manuellen Upfront-Prüfungen und Reflektionen. p>
Tags und Links asp.net-mvc viewmodel automapper editmodel