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

本文关键字:服务 存储 项目 我可以 | 更新日期: 2023-09-27 18:06:42

有这个通用的存储库实现

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

通过它的外观,似乎我可以只有一个单一的通用存储库为我的整个项目和几乎所有的实体在数据库中它会工作得很好。对于那些它没有的,我可以创建一个更具体的存储库,例如MembershipRepository,它派生自基本存储库,并根据需要覆盖方法,例如Find。

现在也可以编写泛型服务类....与上面类似,然后只创建几个更具体的服务。

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

事情肯定没那么简单。这里面有圈套吗?让我们暂时忽略EntityFramework具有内置的存储库+UOW模式,并且不需要存储库模式。

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

我们有。

我真的很纠结。对于较小的域,这是完美的,并且是一种享受。对于较大的存储库(如我目前正在使用的存储库),您的存储库永远不可能真正具有足够的通用性以保证使用单个存储库。

例如,我目前使用的代码库中的通用存储库现在充斥着各种非常具体的方法,如即时获取、分页等。它比它最初的样子好多了。回顾修订历史,曾经只有GetAllGetByIdCreateUpdate方法。现在它有像GetAllEagerFetch这样的东西,重载各种JOIN类型,GetAllPaged, GetAllPagedEagerFetch, DeleteById, ExecuteStoredProcedure, ExecuteSql(恶心)等。还有很多。

解决这个问题的一种方法是遵循接口隔离原则,这样你的存储库就可以是庞大而通用的,而消费者只关心他们需要关心的东西。但我不是特别喜欢。

也就是说,在最近的项目中,我们已经不再使用repository风格的设置。我们现在更喜欢使用具有特定用途的CommandQuery对象的CQRS设置。这更倾向于单一责任原则(而不是遵循"鲍勃叔叔程度")。但是这些类有一些定义良好的职责)