2014-01-28 17 views
7

Lesen a SO question, erkannte ich, dass meine Read-Dienste bieten könnte einige smarter Objekt wie ViewModels statt einfache DTOs. Das lässt mich überdenken, welche Informationen von den von den Read Services zurückgegebenen Objekten zur Verfügung gestellt werden sollten. Vor nur DTOs verwendete mein Read Service eine flache Ansichtszuordnung einer Datenbankabfrage in eine Hash-ähnliche Struktur mit minimaler Normalisierung und ohne Verhalten.Verwenden von ViewModels statt DTOs als Ergebnis einer CQRS-Abfrage

Allerdings neige ich dazu, von einem Ansichtsmodell als etwas „intelligente“ zu denken, die Informationen nicht zur Verfügung gestellt von der Datenbank, wie Statussymbol erzeugt haben kann, berechnete Werte, umformatiert Werte, Standardwerte usw.

Ich beginne siehe zu, dass der Bau einiger Ansichtsmodell Objekte könnte komplizierter und hat mögliche Nachteile, wenn ich meine allgemeinen ReadServiceInterface Rückkehr Viewmodel nur gemacht:

(1) Soll ich einiges Design Beschränkung für die Viewmodel zurück Plan von meiner CQRS? Wie stellen Sie sicher, dass ihre Konstruktion fast so schnell ist wie ein einfaches DTO?

(2) DTOs sind von Natur aus leicht serialisierbar und können in einer SOA-Architektur an ein externes System gesendet oder in eine Nachricht eingebettet werden. Bedeutet dies, dass die Verwendung von ViewModels sich negativ auf meine Architektur auswirken wird?

(3) Welche Art von ViewModels sollte ich außerhalb meiner Read Services behalten?

(4) Sollte ich erwarten, dass alle ViewModels von Read Services abgerufen werden?

In der Vergangenheit habe ich einige ViewModels implementiert, die mehr als eine Abfrage benötigten. In einem CQRS nehme ich an, das ist ein Design-Geruch, da alles, was sie liefern, in nur einer Abfrage sein sollte.

Ich beginne ein neues Projekt, wo ich dachte, dass jede Abfrage entweder Aggregatobjekte oder DTOs zurückgeben wird. Seit dem kommen ViewModels ins Spiel. Ich frage mich:

(5) Sollte ich planen, dass Abfragen innerhalb meiner Architektur zwei Arten von Objekten (ViewModels + Aggregates) oder drei (+ DTO) ergeben?

+0

Nachdem ich diese Frage gestellt hatte, erkannte ich, dass eine unbewusste "alles von Entitäten generierte" Obsession und nicht praktizierender CQRS + MVVM die Ursache meiner anämischen Modelle war! – SystematicFrank

Antwort

6

Ansicht Modelle (VM) dienen einem einzigen Master: die Ansicht. Normalerweise betrachten wir die VM als ein ziemlich dummes Objekt. In dieser Hinsicht gibt es keinen technischen Unterschied zwischen einer VM und einem DTO, nur ihr Zweck und ihre Semantik sind unterschiedlich.

Wie Sie eine VM erstellen, ist ein Implementierungsdetail. Einige VMs werden vorab generiert und in einem VM-Repository gespeichert. Andere werden in Echtzeit von einem Dienst (oder einem Abfrage-Handler) erstellt, indem entweder die Datenbank direkt abgefragt wird oder andere Repos/Dienste abgefragt und dann die Ergebnisse zusammengestellt werden. Es gibt kein richtig oder falsch und keine Regeln darüber, wie es gemacht wird. Es kommt auf die Präferenz an.

In CQRS ist der wichtige Teil die Trennung von Befehlen von Abfragen, d. H. Mehr als ein Modell. Es gibt keine Regel darüber, wie viele Abfragen Sie ausführen sollten oder ob Sie ein Ansichtsmodell oder DTO zurückgeben sollten. Solange Sie mindestens ein Lesemodell für Abfragen haben, ist es CQRS.

Lassen Sie sich nicht durch technische Details verkomplizieren. Bei richtigem Design geht es mehr um High-Level-Struktur und nicht um Low-Level-Implementierung.Verwenden Sie CQRS, weil ein Lesemodell Ihre App vereinfacht, nicht aus anderen Gründen. Streben Sie nach Vereinfachung und sauberem Code, nicht nach starren Regeln, die ein "How to" -Rezept vorschreiben.