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

Posted 2023-04-12

【中文标题】访问存储库中的 UnitOfWork 是不好的设计吗？

【英文标题】：Is it bad design to have access to the UnitOfWork in the Repository?

【发布时间】：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 的建议听起来很适合我。

【参考方案1】：

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

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

【参考方案2】：

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

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

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