Репозиторий против доменных служб

чем больше я изучаю DDD и репозитории, тем больше меня привлекает подход доменных служб.

Что-то мне не нравится, что репозиторий (по крайней мере, в примерах и статьях, которые я читал) не является атомарным с одним оператором.

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

Есть куча вещей, которые мне просто не нравятся об этом. В общем, сам репозиторий вызывает беспокойство и должен поддерживаться (он IDisposable и требует "Commit"). Не похоже, что я так сильно абстрагирую проблемы настойчивости.

Гораздо более простой подход, который, кажется, мне больше подходит:

  GetCustomerService().DeleteCustomer(someCustomer);

Он атомарен. Нет экземпляра репозитория для обслуживания, удаления или сохранения изменений. И если вам ДЕЙСТВИТЕЛЬНО нужна поддержка единицы работы вне единственной операции на агрегированном корне, включите какую-то поддержку области данных (похожую на TransactionScope):

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

В обоих вышеупомянутых случаях, например, ради, Допустим, они находятся в каком-то бизнес-контроллере, а базовый механизм (находящийся внутри репозитория или реализации службы) для доступа к данным - это объектный контекст Entity Framework. А Клиент - это некий совокупный корень.

Пожалуйста, покажите мне, что репозиторий лучше.

Спасибо.

6
задан Jeff 20 December 2010 в 07:13
поделиться