存储库vs域服务

我越是探索DDD和存储库，我越感觉自己被吸引到域服务方法。存储库vs域服务

我的直觉中的某些东西并不喜欢这样一个事实，即一个存储库（至少在我读过的示例和文章中）不是单个语句的原子。

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

这里有一堆我不喜欢的东西。一般来说，存储库本身成为一个问题，必须维护（它是IDisposable并需要“提交”）。看起来我并没有把持续性问题抽象得很多。

，似乎坐在我的直觉更好

一个更简单的方法是：

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); 
}

在两个以上，例如起见，可以说他们在某个业务控制器中，而数据访问的底层机制（坐在存储库或服务实现中）是一个实体框架ObjectContext。而客户是一些聚合根。

请告诉我，存储库方法更好。

谢谢。

来源

2010-12-20 Jeff

+1;不同意，但我喜欢这个问题 – Marijn 2010-12-21 14:39:48

我想说，你只看到了存储库模式的天真例子。没有什么说知识库应该有原子方法。

我的做法是相当多的，以你的Datascope公司的做法相同：

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

（我的做法是基于麦Nilssons NWorkspace的想法在他的书中应用领域驱动设计和模式）

这样，我可以将不同类型的UoW传递给我的存储库。例如基于EF4的uow或linq到基于对象的uow，并且仍然在存储库内使用相同的linq查询。

来源

2010-12-20 08:51:15

你似乎用Unit Of Work代替了我的问题。 – Jeff 2010-12-20 15:27:12

Roger解决了他的UoW的真正担忧：“维护受业务事务影响的对象列表，并协调写出更改和解决并发问题。” （福勒）。这是在大多数非平凡应用程序中需要解决的_事务性变化_相关_业务对象。 – Marijn 2010-12-21 14:37:53

在现代ORM支持的数据访问层中，不应该由ORM本身来协调事务性更改，因为在大多数情况下，单个对象/实体图正在保存？ – Jeff 2010-12-21 14:59:43

存储库vs域服务

回答

相关问题