Wie wird Command Query Separation (CQS) implementiert, wenn mit Hilfe eines ORM?

Question

Das Prinzip hinter dem CQS Architekturmuster ist, dass Sie Ihre Fragen trennen und Befehle in getrennte Wege. Idealerweise kann Ihre persistenten Speicher lesen / schreiben partitioniert werden, aber in meinem Fall gibt es eine einzige, normierte Datenbank.

Wenn Sie ein ORM (NHibernate in meinem Fall) verwenden, ist es klar, dass die ORM verwendet wird, wenn Befehle ausgeben. Aber was ist mit all den verschiedenen Fragen, die Sie ausführen müssen Daten formen (DTOs) für Benutzerbildschirme, ist es üblich, die ORM zu Graben, wenn die Abfrageseite CQS tun?

Wo soll ich meine Fragen und DTO Projektionen implementieren? Gerade ADO.NET (Datareaders, dtos, Datentabellen, gespeicherte Procs)? Einige Abfragen sind ziemlich einzigartig und eine Menge beinhalten alles zusammen ziehen verbindet. Ich möchte nicht, die Datenbank für die Abfragen denormalize, aber ich konnte erstellen Ansichten (armen Mannes Denormalisierung).

Answer 1

Ich gehe davon aus von CQS meinen Sie das DDD Architekturmuster aka CQRS , nicht unbedingt die traditionellen CQS Prinzip.

ich noch NHibernate verwenden würde für Nur-Lese-Modell. Es gibt viele Vorteile, wie Zukunft und Multi-Abfragen, faul / eager loading etc ..., die DB chattiness optimieren. Darüber hinaus wird es einfacher sein, Abfragen mit einem ORM zu komponieren, wenn die Benutzeroberfläche für den Anwender ermöglicht, im Wesentlichen der Änderung where-Klausel.

In Bezug auf, wie man technisch ein Nur-Lese-Modell handhaben, können Sie eine Entität unveränderliche markieren mit NHibernate. Sie könnten markieren Sie einfach alle Ihre Lesemodellentität unveränderlich. Auch ich glaube nicht, Sie Projektionen in NHibernate aktualisieren können, so dass eine weitere Option für gehen als nur lesen Modell (Jemand bitte korrigieren Sie mich, wenn ich falsch bin, wie ich nicht 100% sicher bin).

In Bezug auf hässlich oder unmöglich NH-Mappings: NH können Ansichten Karte und Stored Procedures, so denke ich, es wäre in Ordnung diese zu verwenden, wenn Sie benötigen. Ansichten sind wahrscheinlich ein bisschen flexibler als gespeicherte Prozeduren für ein Nur-Lese-Szenario, weil Ihre SQL noch dynamisch sein wird. Wenn Sie benötigen jedoch / Schreib für jede dieser abgeflachten Strukturen las ich in ein Geschäft Prozedur Karte würde.

Answer 2

Letztlich ist die Idee, dass Sie sollten verwenden, was die Abfrage-Kanal macht für Sie am einfachsten zu bauen und zu pflegen. Sie müssen nicht mehr über Updates kümmern, Geschäftsregeln durchzusetzen, Datenintegrität erhalten bleibt oder sogar Lasttransport (zum größten Teil). Sie sind also frei viele Optionen zur Auswahl, die zuvor nicht auf dem Tisch waren.

Aber NHibernate kann immer noch eine gute Option sein ... es ist einfach nicht mehr die automatische Voreinstellung (die es manchmal für die Befehlsseite ist).

Wir haben gewählt Castle Active Record zu verwenden (die auf NHibernate unter der Haube basieren), vor allem, weil es eine nette Funktion, die für Sie einen Tisch aus einer Klasse generieren. Das passt hervorragend für uns, denn hier ist unser Workflow: Erstens haben wir eine Viewmodel-Klasse erstellen. Diese Klasse ist ganz auf die Bedürfnisse der Ansicht geformt. Dann markieren wir das Ansichtsmodell mit Castle Active Record-Attribute. Dann fragen wir Active Record die entsprechende Tabelle für diese Klasse in der Query-Datenbank zu generieren. Dies ist die schnellste, glatteste, wie wir schnell gefunden haben, um eine Abfrage-Datenbanktabelle zu erhalten, die die Viewmodel-Klasse dient. Die automatische Generierung spiegelt die Realität, dass der einzige Grund, besteht die Tabelle ist die Ansicht, zu dienen.

Answer 3

Wir sind mit EF für den Befehlsteil und gerade ADO.NET => DTOs für die Suche nach Kette. Vorteile:

1) Die Fähigkeit von SQL-Abfragen zu optimieren und erweiterte DB-Speicher verwenden Funktionen, die nicht in ORM-Schicht abstrahiert

2) Weniger Aufwand

Aber wir verwenden die Trennung nur für anspruchsvolle Teile (Suche), verlässt sich der Rest auf gemeinsames Modell Entity Framework.

Answer 4

Es gibt keine Notwendigkeit, einen anderen Ansatz zu verwenden, um Ihre Datenbank zu lesen vs. Ihre Datenbank zu aktualisieren. CQS einfach besagt, dass Befehle, die Aktualisierung des Datenspeicher sollte aus den Abfragen getrennt sein, den Zustand aus dem Datenspeicher gelesen werden.

Sie können nach wie vor NHibernate verwenden von Ihrem Datenspeicher zu lesen, aber möchten Sie vielleicht, um es durch die Schaffung von zwei verschiedenen Klassen deutlich machen, auf Ihre Daten zugreifen kapseln. Eine Klasse würde Methoden zu lesen (Abfrage), um die Daten zu speichern, die andere Klasse würde Methoden Befehle zu erteilen (Hinzufügen, Ändern, Löschen) auf den Datenspeicher.

Was Sie versuchen zu vermeiden, ist eine Methode, die eine Nachricht aus der Datenbank bekommt, und dann markiert die Nachricht als in der Datenbank gelesen. Dies sollte zwei verschiedene Methodenaufrufe sein. Sie sollten nicht den Zustand ändern und einen Wert aus der gleichen Methode zurück.

Answer 5

Ich mag getrennt halten ORM für liest und schreibt so würde ich (und ich verwende):

Nhibernate für Befehle - schön abbildet mein Domain-Modell

Dapper.net für Anfragen - schön abbildet meine DTO und ermöglicht felxibility, wenn die Abfrage zu komplex ist,

.

Sie sind ein perfektes Paar wie Han Solo und Chewbacca.