Depósito vs Servicios de dominio

Question

Cuanto más exploro DDD y repositorios, más me siento atraído por un enfoque de servicios de dominio.

Algo en mi interior no le gusta el hecho de que un repositorio (al menos en los ejemplos y artículos que he estado leyendo) no es una declaración única atómica.

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

Hay un montón de cosas que simplemente no me gustan sobre esto. En general, el repositorio se convierte en una preocupación y debe mantenerse (es IDisposable y requiere un "Compromiso"). No parece que estoy abstrayendo demasiado la persistencia.

Un enfoque mucho más simple que parece que sentarse mejor en mi tripa es:

GetCustomerService().DeleteCustomer(someCustomer); 

Es atómica. No hay ninguna instancia de un repositorio para mantener, eliminar o guardar cambios. Y si realmente necesita la unidad de soporte de trabajo fuera de una operación en una raíz agregada, incorporar algún tipo de apoyo ámbito datos (similar a un TransactionScope):

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

En las dos anteriores, por el bien de ejemplo , digamos que están en algún controlador comercial y el mecanismo subyacente (que se encuentra dentro del repositorio o la implementación del servicio) para el acceso a los datos es un ObjectContext Entity Framework. Y un cliente es una raíz agregada.

Por favor, muéstrame que un enfoque de repositorio es mejor.

Gracias.

Answer 1

Diría que solo has visto ejemplos ingenuos de patrones de repositorios. No hay nada que diga que un repositorio debe tener métodos atómicos.

Mi enfoque es prácticamente idéntica a su acercamiento Datascope:

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

(Mi enfoque se basa en las ideas Jimmy Nilssons NWorkspace en su libro La aplicación de dominio determinadas por el diseño y los patrones)

esta manera, puede pasar diferentes tipos de UoW a mis repositorios. p. un uow basado en EF4 o un linq para objetos basados ​​en uow y todavía usan las mismas consultas de linq dentro de los repositorios.