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ę.
+1; zdecydowanie się nie zgadzam, ale podoba mi się pytanie: – Marijn