有这种通用的存储库实现
http://www.itworld.com/development/409087/generic-repository-net-entity-framework-6-async-operations
从它的外观来看,似乎我可以只为我的整个项目拥有一个通用存储库,并且对于数据库中的几乎所有实体,它都可以正常工作。对于它没有的那些,我可以创建一个更具体的存储库,例如MembershipRepository
派生自基础存储库并根据需要覆盖方法,例如查找。
现在也可以编写一个通用服务类....与上面类似,然后只创建一些更具体的服务。
这将大大减少项目规模。无需为每个实体编写冗余存储库,也不需要编写更少数量的服务层类。
当然不能那么简单。有没有抓住这个?让我们暂时忽略EntityFramework内置了存储库+ UOW模式,并且不需要存储库模式。
答案 0 :(得分:3)
我们这样做。
我老老实实地被撕裂了。对于较小的领域,它非常精细,并且是一种享受。对于较大的(就像我目前使用的那个),你的存储库永远不会真正通用来保证一个。
例如,我目前使用的代码库中的通用存储库现在充斥着各种非常具体的方法,例如渴望获取,分页等。它远远超过它的开始。回顾修订历史记录,它曾经只有GetAll
,GetById
,Create
和Update
方法。现在它有GetAllEagerFetch
之类的内容,包含各种JOIN
类型的重载,GetAllPaged
,GetAllPagedEagerFetch
,DeleteById
,ExecuteStoredProcedure
,ExecuteSql
(哎呀)等等还有很多。
解决这个问题的一种方法是跟随Interface Segregation Principle,以便您的存储库可以是庞大且通用的,但消费者只关心他们需要关注的内容。我不是特别喜欢那样。
话虽如此 - 我们已经在最近的项目中摆脱了Repository风格的设置。我们现在更喜欢使用具有特定目的的Command
和Query
对象进行CQRS设置。这倾向于更倾向于Single Responsibility Principle(不遵循“叔叔鲍勃度”......但是这些类有一些明确的职责)。