工作单元应该指向服务层还是存储库？

Question

只是想知道，在带有实体框架的ASP.NET MVC3环境中。工作单元应该指向服务层还是存储库（然后存储库指向服务层）？

我看过两个例子：

• 一个工作单元和存储库都具有服务层实例的实例。

链接：实体框架4 CTP 4 / CTP 5通用存储库模式和可测试的单元

不使用服务层，但显然可以在这种情况下使用。

• 其次，工作单元在存储库中有一个实例，在服务层中有一个实例。

链接：http：//blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit- of-work-patterns-with-entity-framework-4-0.aspx

有什么会更好？

谢谢。

Answer 1

事实上，如果你仔细想想，控制器应该与工作单元一起工作。

通常，在 ASP.NET MVC 应用程序中，当 HTTP 请求传入时，控制器会被分配一个新的工作单元。

然后，控制器将调用服务上的方法（调用存储库上的方法），获取实体框架内部图形/内存并对其进行更改。

一旦控制器完成了它需要做的事情，它将对工作单元执行“提交”，这会导致对底层存储库的任何更改都提交到数据库。

我假设当您谈论“服务”时，您的控制器和存储库之间有一个中间层，其中控制器仅与服务通信，然后服务与存储库通信，然后备份应用程序堆栈。

所以你的控制器可能看起来像这样：

public class ProductsController : Controller
{
   private IUnitOfWork _unitOfWork;
   private IProductsService _service;

   public ProductsController(IUnitOfWork unitOfWork, IProductsService service)
   {
      // use dependency injection here
      _unitOfWork = unitOfWork;
      _service = service;
   }

   [HttpPost]
   public ActionResult SubmitOrder(Product p)
   {
      var existingProduct = _service.FindById(p.ProductId);
      UpdateModel(existingProduct);
      _unitOfWork.Commit();
   }
} 

在大多数 EF4 场景中，工作单元被实现为 ObjectContext 的包装器。换句话说，工作单元上的“Commit”方法将简单地在 ObjectContext 上执行“SaveChanges”。

因此，工作单元并不真正指向服务或存储库。它只是与所管理的持久性机制一起工作。

Answer 2

我不确定你所说的“指向”是什么意思，但我认为事务是服务层的责任，而不是持久性。

持久性对象无法知道它是否是更大工作单元的一部分。负责的服务具有对构成工作单元的所有模型和持久性对象的引用。该服务还负责代表持久性对象管理来自池的连接。获取连接，打开事务，执行工作，提交或回滚事务，然后关闭连接。这就是服务的工作。