访问存储库中的 UnitOfWork 是不好的设计吗？答案

【问题标题】：Is it bad design to have access to the UnitOfWork in the Repository?访问存储库中的 UnitOfWork 是不好的设计吗？
【发布时间】：2013-05-02 18:24:09
【问题描述】：

背景：Entity framework4.1 和 MVC4

我的设置有模型实体，然后是通用存储库，然后是从通用存储库继承的 UserRepository、ProductRepository 等特定存储库的模型。

然后我有一个使用这些存储库以及任何业务逻辑的服务层，并且可以在此处访问 UnitOfWork 对象以调用 Commit。

使用工作单元模式，我的问题是：

让存储库层可以访问 UnitOfWork 对象是不是很糟糕？

对我来说，这似乎是一个“泄漏”，因为现在事情可能在你甚至没有意识到的时候就已经提交了。

这对吗？

例如

public class ProductService
{


   public void SaveProduct(Product product)
   {
      try
      {
        productRepository.Save(product);
        statsRepository.Update(product);
        this.UnitOfWork.Commit();
      } catch(..) 
      {
            //
      }
      finally()
      {
        //
      }


   }

}

现在，如果其中任何一个调用失败，则不会调用 commit。

但是如果在 abcRepository 层中您可以访问 UofW 对象并调用了 commit，它的行为方式就会不一致。

【问题讨论】：

在我看来，创建工作单元的事物应该有责任成为提交者。存储库可能没有该特定工作单元的完整上下文。
我之前看到UnitOfWork 的方式是UnitOfWork 可以访问存储库，而不是相反。
@Matthew 所以在我的例子中这将在 MVC 控制器中，然后我将它传递给 ABCService 类。
我认为这是有道理的，@Charles380 的建议听起来很适合我。

标签： c# asp.net-mvc-4 transactions entity-framework-4.1 unit-of-work

【解决方案1】：

我认为这是实现存储库和 UnitofWork 的正确方法

http://code.cmsstores.com/implementing-unit-of-work-pattern-dot-net/

【讨论】：

【解决方案2】：

我认为存储库不应该访问 u-o-w，正如 Matthew 已经评论的那样。您的问题几乎可以自行回答。

回复：现在，如果其中任何一个调用失败，则不会调用 commit。 -

一般来说，这很好，对吧？您不想部分提交更改。

【讨论】：