我可以在整个项目中只使用通用存储库和通用服务类吗？

Question

有这个通用存储库实现

http://www.itworld.com/development/409087/generic-repository-net-entity-framework-6-async-operations

从表面上看，我似乎可以为整个项目提供一个通用存储库，并且对于数据库中的几乎所有实体来说，它都可以正常工作。对于那些没有的存储库，我可以创建一个更具体的存储库，例如MembershipRepository，它派生自基本存储库并根据需要覆盖方法，例如查找。

现在，人们也可以编写一个通用服务类......与上面类似，然后仅创建一些更具体的服务。

这将大大减少项目规模。无需为每个实体编写冗余存储库，并且服务层类的数量也少得多。

事情肯定不可能这么简单。这有什么问题吗？让我们暂时忽略 EntityFramework 内置了存储库 + UOW 模式，并且不需要存储库模式。

Answer 1

我们的确是。

老实说，我对此感到很痛苦。对于较小的领域来说，它非常好并且很有效。对于较大的存储库（例如我当前正在使用的存储库），您的存储库永远不可能真正通用到足以保证单个存储库。

例如，我当前使用的代码库中的通用存储库现在散布着各种非常具体的方法，例如热切获取、分页等。它比最初的要多得多。回顾修订历史，它曾经只有GetAll、GetById、Create和Update方法。现在它有诸如GetAllEagerFetch各种类型的重载之类的东西，，，，，JOIN（恶心）等等。还有更多。GetAllPagedGetAllPagedEagerFetchDeleteByIdExecuteStoredProcedureExecuteSql

解决这个问题的一种方法可能是遵循接口隔离原则，这样您的存储库就可以是巨大且通用的，但消费者只关心他们需要关心的内容。不过我不是特别喜欢这样。

话虽如此，我们在最近的项目中已经放弃了存储库样式的设置。我们现在更喜欢使用具有特定用途的对象的CQRS设置。相反，这更倾向于单一职责原则（不遵循“鲍勃叔叔程度”......但这些类有一些明确定义的职责）。CommandQuery