Arbeitseinheit mit mehreren Datenquellen?

Question

Es ist möglich (sogar wahrscheinlich), dass ich einfach nicht vollständig das Konzept einer grokking „Einheit der Arbeit.“ Im Grunde genommen, ich sehe es als eine Art einer breiten Transaktion in einer objektorientierten Umgebung verwendet. Starten Sie die Arbeitseinheit, die Interaktion mit den Objekten, begehen oder Rollback. Aber wie funktioniert diese Pause bis zu den tatsächlichen Transaktionen auf den Datenspeicher hinter diesen Objekten?

In einem System mit einem einzigen DB und einem ORM (wie NHibernate) ist es einfach. Die Transaktion kann durch die ORM aufrechterhalten werden. Aber was ist ein System, in dem die benutzerdefinierten Domain-Modelle viele unterschiedliche Datenquellen sind verschleiern? Und nicht alle diese Datenquellen sind relationale Datenbanken? (Es gibt eine Menge auf dem Dateisystem gemacht hier.)

Im Moment bin ich auf der Idee fest, dass „man nicht einfach eine Transaktion über eine SQL2005 DB, ein SQL2000 DB, eine DB2-DB, und das Dateisystem alle in dem gleichen‚atomaren‘Geschäftsbetrieb aufrechterhalten kann.“ So jetzt ist es in der Verantwortung der Entwickler im Team (die in der Regel unabhängig voneinander arbeiten) Transaktionen manuell in dem Code zu erhalten. Jede DB kann auf sie richtige Transaktionen, aber der Geschäftsbetrieb als Ganze wird manuell geprüft und all bedeutenden Schritt auf dem Weg ausgeglichen.

Doch mit Komplexität in der Domäne und Standardentwickler Umsatz zu erhöhen, wird dieser Ansatz immer schwieriger und fehleranfällig im Laufe der Zeit.

hat jemand irgendwelche Ratschläge oder Beispiele dafür, wie eine Domain wie könnte dies am besten angesprochen werden, oder, wie es war, bevor angesprochen? Die eigentliche „Domain“ ist in diesem Fall immer noch sehr in den Kinderschuhen, entwickelt sich als ein Prototyp eines Tages erweitern und verbrauchen / ein großes Ökosystem von disparaten Legacy-Anwendungen ersetzen. Es gibt also viel Platz für Neugestaltung und Refactoring.

Als Referenz ein 10.000 Fuß Blick auf den Entwurf, den ich zur Zeit für Ziel habe, ist: Eine große Sammlung von klein-dumb-as-möglich-Client-Anwendungen einen zentralen Message-basierten Dienst aufrufen. Der Service ist der Eingang in die „Domäne Kern“ und kann als eine große MVC-Stil Anwendung gedacht werden. Anfragen werden an den Service gemacht (ähnlich wie „Aktionen“), die von Handler werden abgeholt (ähnlich wie „Controller“). Alles, was verfahrens geht es. Sie interagieren mit den Modellen, die alle Geschäftsregeln enthalten. Die Modelle veröffentlichen, um Ereignisse, die Zuhörer ( „Dienste“? Dieser Teil noch bewölkt in der Konstruktion ist und vorbehaltlich der Verbesserung) abholen und Griff von Repositorys (Datenbank x, y-Datenbank, Dateisystem, E-Mail, jede externe Ressource) interagieren. Alle fröhlich abhängigkeits injiziert entsprechend.

Es tut uns leid für alle Ausführlichkeit :) Aber wenn jemand einen Rat hat, würde ich gerne hören. Auch (vor allem), wenn dieser Rat ist „Ihr Design ist schlecht, versuchen Sie dies stattdessen ...“ Danke!

Answer 1

ich vorher auf einem System gearbeitet, das dies erreichen könnte, und es ist relativ einfach. Da Sie ist in seinen frühen Stadien projiziert, vielleicht könnte dies nützliche Informationen für Sie sein. Leider habe ich keinen Zugriff mehr auf den Code, aber ich bin immer noch komfortabel zu beschreiben, wie es funktioniert.

Was hatte ich getan wurde meine Repositories baute eine generische Repository-Muster Implementierung verwenden. Der Basis-Repository-Typ würde immer Referenzen werden von den Diensten und UOW. Aus Gründen der Diskussion werden wir es nennen BaseRepository. „T“ würde IEntity Implementierungen beschränkt werden, die ein Domain-Objekt bezeichnet. Vom BaseRepository hatte ich einen anderen Satz von Basisklassen erstellt für Compositing, wie SqlBaseRepository, XmlBaseRepository, etc.

Die UOW kümmert sich nur, dass etwas von der Art BaseRepository ist, das ist, wo die Kernfunktionalität existieren würde. Grund CUD (von CRUD) würde dargestellt werden, erstellt die Mittel für die Bereitstellung, Aktualisierungen und Löschungen. Was jeder von ihnen tun würde, wäre, einen Delegierten zu erstellen und sie in einer Warteschlange in der UOW platzieren, auch entlang Informationen wiedergeben, was Art der Transaktion, es würde sein, und die entsprechenden Daten erforderlich, um es zu vervollständigen. Die UOW beginnen würde, eine Liste der Aufrechterhaltung was Repositories würden in der Transaktion beteiligt sein müssen, aber trotzdem war es egal, welche Art es war. Effictively, hier Schlange stehen, ist wie in einer Transaktion Anwerbung.

definiert Die BaseRepository eine abstrakte Methode namens so etwas wie .ApplyChange (). Sobald .Commit () wurde auf der UOW genannt, wäre es eine Transaction create () und starten Sie die Kongressteilnehmer in der Liste aufrufen, vorbei an der Informationen zu .ApplyChange zurück (). Die tatsächliche Implementierung von .ApplyChange () existiert in der spezifischen Repository Basis, das heißt die SqlRepositoryBase etc. und durch die Umsetzung außer Kraft gesetzt werden könnte, wie gut.

Wo wird es knifflig, zumindest für mich, rollt zurück. Ich befassen sich nur mit einer einzigen Datenbank, aber manchmal dateibasierte Änderungen hatte, die gemacht wurde. Ich habe eine .RevertChange () -Methode und begannen den ursprünglichen Zustand zu verfolgen und modifizierten Zustände, so dass ich im Grunde ein Reverse-Delta anwenden könnte, um wieder, wo ich auf dem Dateistapel war.

Ich wünsche, dass ich spezifischere über die Umsetzung sein könnte, aber es ist mehr als ein Jahr her, dass ich den Code jetzt gesehen haben. Ich kann Ihnen sagen, dass die Grundlage für den originalen Code aus dem Buch getragen wurde, .NET Domain- Driven Design mit C #: Problem - Entwurf - Lösung von Tim McCarthy. Eine große Menge an meinem Repository Implementierung wurde auf seinen Beispielen basieren, mit einer großen Mehrheit meiner Anpassung in auf dem UOWs und deren Umsetzung kommen.

Ich hoffe, das hilft, ein wenig! : -)