2010-12-20 11 views
6

im więcej eksploruję DDD i repozytoriów, tym bardziej odczuwam, że jestem bardziej zainteresowany podejściem do usług domenowych.Repozytorium a usługi domenowe

Coś w moim wnętrzu nie podoba się faktowi, że repozytorium (przynajmniej w przykładach i artykułach, które czytałem) nie jest pojedynczą instrukcją atomową.

using (var customerRepository = GetCustomerRepository()) 
    { 
     customerRepository.AddCustomerForDelete(someCustomer); 
     customerRepository.SaveChanges(); 
    } 

Jest kilka rzeczy, które po prostu mi się nie podobają. Zasadniczo samo repozytorium staje się przedmiotem troski i musi być utrzymywane (jest to IDisposable i wymaga "Commit"). Nie wydaje mi się, żebym wyabstrahował wytrwałość.

znacznie prostsze podejście, które wydaje się lepiej siedzieć w moim jelicie jest:

GetCustomerService().DeleteCustomer(someCustomer); 

To atomowej. Nie ma instancji repozytorium do utrzymywania, utylizacji lub zapisywania zmian. A jeśli naprawdę naprawdę potrzebują jednostkę wsparcia pracy poza pojedynczej operacji na łączną root, zawierają jakieś wsparcie zakres danych (zbliżona do TransactionScope):

using(var ds = new DataScope()) 
{ 
    // both of these happen under the same underlying DbConnection or whatever 
    GetCustomerService().DeleteCustomer(someCustomer1); 
    GetCustomerService().DoSomethingElse(someCustomer2); 
} 

w obu wyżej, przez wzgląd na przykład za , powiedzmy, że są w jakimś kontrolerze biznesowym, a mechanizmem bazowym (siedzący wewnątrz repozytorium lub implementacją usługi) dostępu do danych jest Entity Framework ObjectContext. A klient to jakiś zagregowany root.

Proszę pokazać, że podejście do repozytorium jest lepsze.

Dziękuję.

+0

+1; zdecydowanie się nie zgadzam, ale podoba mi się pytanie: – Marijn

Odpowiedz

2

Powiedziałbym, że widziałeś tylko naiwne przykłady schematu repozytorium. Nic nie mówi, że repozytorium powinno mieć metody atomowe.

Moje podejście jest prawie identyczny do podejścia Datascope:

using(var uow = UoW.Begin()) 
{ 
    var customerRepo = new CustomerRepository(uow); 
    customerRepo.Remove(someCustomer); 
    uow.Commit(); 
} 

(Moje podejście opiera się na Jimmy Nilssons NWorkspace pomysłów w książce Ubiegających Domain Driven Design i wzory)

ten sposób, że może przekazywać różne typy plików UoW do moich repozytoriów. np. Uow oparte na EF4 lub linq do obiektów opartych na uow i nadal używają tych samych zapytań linq wewnątrz repozytoriów.

+0

Wygląda na to, że właśnie zastąpiłeś moje obawy repozytorium z Jednostką Pracy. – Jeff

+0

Roger zwraca się do firmy UoW z prawdziwą troską: "Utrzymywanie listy obiektów dotkniętych transakcją biznesową i koordynowanie zapisywania zmian i rozwiązywania problemów z współbieżnością." (Ptasznik). Jest to "zmienna transakcja" na _related_ obiektów biznesowych, którą należy rozwiązać w większości nietrywialnych aplikacji. – Marijn

+0

Czy w nowoczesnej warstwie dostępu do danych typu ORM nie należy wprowadzać zmian transakcyjnych w samej ORM, ponieważ w większości przypadków zapisywany jest pojedynczy wykres obiektu/obiektu? – Jeff