从类中调用存储库模式和UnitOfWork

Question

我对存储库模式很陌生，可以非常清楚地看到它的好处。但是我认为UnitOfWork类调用的东西很麻烦（当过滤器选项传入db调用时）

我想将这个unitOfWork对象传递给我的数据对象，让它们处理杂乱的东西。

例如，如果我有一个Customer，Address和Account对象，我想让Account对象处理其子对象（Customer和Address）的获取和保存，并处理数据的获取，以便可以GetAccounts（）的一些重载采用各种参数来启用过滤。

然而，由于我是这种模式的新手，我不确定这是一种处理它的好方法。我打算做什么考虑到糟糕的编程？或者它是使用存储库模式的完全可接受的方式吗？

Answer 1

工作单元不应该是凌乱的，它只是允许对存储库中的几个操作等原子进行操作。

关于存储库模式的一个常见批评是，当你实际使用诸如EF之类的ORM来实现它时，它有时会被过度使用，并且你最有可能永远不必为不同的ORM进行更改。更重要的是，至少EF还为您提供了工作单元，因此您也不需要它。

一旦确定要同时使用它们，就必须选择从存储库中检索数据的方式。实际上，哪些实体拥有自己的存储库？你在使用DDD吗？然后，您可能希望仅为聚合提供存储库，并通过它们上的方法处理其余的存储库，从而封装业务逻辑。例如，您可以确定Customer是包含Account个对象的聚合根。如果是这种情况，那么Customer.GetAccounts()就完全合情合理，或者甚至只是Accounts的集合。

顺便说一句，对于过滤，我建议接收一个Filter对象列表以避免人口过多的接口。

我很抱歉，如果我看起来很模糊，但它是一个相当广泛的主题，解决方案在很大程度上取决于您的域名，复杂性和要求。

Answer 2

  

然而，我认为UnitOfWork类使得调用时非常麻烦（当过滤器选项传入db调用时）

将过滤器选项传递给db调用时，不使用

工作单元模式。

Unit-of-Work的主要职责是处理业务交易。

  

“工作单元会跟踪您在业务事务中可能影响数据库的所有操作。完成后，它会计算出因工作而需要更改数据库的所有操作。 “作者Martin Fowler

使用查询规范从您的数据源（例如数据库）中检索数据是repositories的责任。

  

如果我有Customer，Address和Account对象，我想让Account对象处理其子对象（Customer和Address）的获取和保存，并处理数据的提取以便可以有一个数字GetAccounts（）的重载过程采用各种参数来启用过滤。

如果你想让Account对象处理其子对象的获取和保存（客户和地址，那么在an object carries both data and behavior时它将类似于Active Record pattern。< /强>

如果要在domain model和data access layer 之间拆分数据和行为职责，您可以将所有数据职责移至AccountRepository类，因为您的Account实体看起来像AggregateRoot