Jednostka pracy z wieloma źródłami danych?

Question

Jest możliwe (nawet prawdopodobne), że po prostu nie w pełni pogrążam pojęcie "jednostki pracy". Zasadniczo uważam to za rodzaj szerokiej transakcji wykorzystywanej w środowisku obiektowym. Uruchom jednostkę pracy, interakcję z obiektami, zatwierdzenie lub wycofanie. Ale w jaki sposób rozkłada się to na rzeczywiste transakcje w magazynach danych znajdujących się za tymi obiektami?

W systemie z pojedynczym DB i ORM (np. NHibernate) jest to łatwe. Transakcja może zostać utrzymana za pośrednictwem ORM. Ale co z systemem, w którym niestandardowe modele domen zasłaniają wiele różnych źródeł danych? I nie wszystkie z tych źródeł danych są relacyjnymi bazami danych? (Tutaj dużo się dzieje w systemie plików.)

W tej chwili utknąłem na idei, że "po prostu nie można utrzymywać transakcji przez DB SQL DB2, DB SQL2000, DB2 DB, i system plików w tej samej "atomowej" operacji biznesowej. " Na razie to odpowiedzialność deweloperów w zespole (którzy generalnie pracują niezależnie od siebie) w celu utrzymania transakcji ręcznie w kodzie. Każdy DB może mieć na nim odpowiednie transakcje, ale operacja biznesowa jako całość jest ręcznie sprawdzana i równoważona na każdym znaczącym etapie.

Jednak wraz ze wzrastającą złożonością domeny i standardowymi obrotami deweloperów, podejście to stanie się coraz bardziej trudne i podatne na błędy w miarę upływu czasu.

Czy ktoś ma jakieś porady lub przykłady tego, jak najlepiej rozwiązać tę domenę lub w jaki sposób adresowano ją wcześniej? Faktyczna "domena" w tym przypadku jest w dalszym ciągu bardzo wczesna, ewoluując jako prototyp do pewnego dnia rozszerzania i konsumowania/zastępowania dużego ekosystemu odmiennych starszych aplikacji. Jest więc dużo miejsca na przeprojektowanie i re-factoring.

Dla porównania, projekt, o którym obecnie myślę, to 10 000 stóp to: Duża kolekcja małych, tak nieistotnych aplikacji klienckich, które wywołują centralną usługę opartą na wiadomościach. Usługa jest wejściem do "rdzenia domeny" i może być uważana za jedną dużą aplikację w stylu MVC. Wnioski są składane do usługi (podobnie jak "działania"), które są odbierane przez procedury obsługi (podobnie jak "kontrolery"). Wszystko, co proceduralne idzie tam. Komunikują się z modelami, które zawierają wszystkie reguły biznesowe. Modele publikują zdarzenia, które nasi słuchacze ("usługi" - ta część jest wciąż pochmurna w projekcie i podlega ulepszeniom) przechwytują i obsługują, wchodząc w interakcje z repozytoriami (baza x, baza danych y, system plików, poczta e-mail, dowolny zasób zewnętrzny). Wszystkie radosne uzależnienia - odpowiednio wstrzyknięto.

Przepraszam za wszystkie gadatliwość :) Ale jeśli ktoś ma jakąkolwiek radę, bardzo bym to usłyszał. Nawet (szczególnie) jeśli ta rada jest "twój projekt jest zły, spróbuj tego zamiast ..." Dzięki!

Answer 1

Wcześniej pracowałem nad systemem, który mógłby to osiągnąć i jest dość prosty. Ponieważ projekt jest na wczesnym etapie, może to być przydatne dla Ciebie. Niestety, nie mam już dostępu do kodu, ale nadal dobrze opisuję jego działanie.

To, co zrobiłem, to zbudowanie moich repozytoriów za pomocą ogólnej implementacji schematu repozytorium. Typ bazowego repozytorium zawsze będzie referencjami usług i UU. Ze względu na dyskusję nazwiemy to BaseRepository. "T" byłby ograniczony do implementacji IEntity, które oznaczały obiekt domeny. Z BaseRepository utworzyłem inny zestaw klas bazowych do compositingu, takich jak SqlBaseRepository, XmlBaseRepository, itp.

The UoW dba tylko o to, że coś jest typu BaseRepository, czyli tam, gdzie istnieje podstawowa funkcjonalność. Podstawowy CUD (CRUD) będzie reprezentowany, zapewniając odpowiedniki Creations, Updates i Deletes.To, co zrobiłby każdy z nich, to utworzenie delegata i umieszczenie go w kolejce wewnątrz UU, a także przekazanie informacji o rodzaju transakcji, a także odpowiednich danych wymaganych do jej ukończenia. UoW zacznie utrzymywać listę repozytoriów, które będą musiały być zaangażowane w transakcję, ale wciąż nie obchodziło go, jaki to był typ. Efektywnie, stawianie w kolejce tutaj jest jak rejestracja transakcji.

The BaseRepository zdefiniował abstrakcyjną metodę o nazwie coś takiego jak .ApplyChange(). Kiedy funkcja .Commit() została wywołana w UUW, utworzyłaby TransactionScope() i zaczęła wywoływać delagaty na liście, przekazując informacje do .ApplyChange(). Rzeczywista implementacja .ApplyChange() istnieje w konkretnej bazie repozytoriów, tj. SqlRepositoryBase, itd. I może być nadpisana przez implementację.

Tam, gdzie to było trudne, przynajmniej dla mnie cofało się. Zajmowałem się tylko jedną bazą danych, ale czasami wprowadzano zmiany oparte na plikach. Dodałem metodę .RevertChange() i zacząłem śledzić stan pierwotny i stany zmodyfikowane, dzięki czemu mogłem zasadniczo zastosować odwrotną deltę, aby powrócić do miejsca, w którym znajdowałem się na stosie plików.

Życzę sobie, abym mógł być bardziej szczegółowy na temat wdrażania, ale minął już ponad rok, odkąd widzę kod teraz. Mogę ci powiedzieć, że podstawą oryginalnego kodu była książka, .NET Domain-Driven Design with C#: Problem - Design - Solution, autorstwa Tima McCarthy. Duża część mojej implementacji repozytorium została oparta na jego przykładach, przy czym znaczna większość moich dostosowań dotyczyła UUW i ich implementacji.

Mam nadzieję, że to pomoże! :-)