在组织上,在使用实体框架代码优先时,我应该在哪里放置常见查询？

Question

在组织上,在使用实体框架代码优先时,我应该在哪里放置常见查询？

Sco*_*ord 23 .net entity-framework entity-framework-4.1

我正在使用EF 4.1 Code First布局一个新的数据层,从较旧的自制数据层迁移.

我已经设置了两个程序集,一个用于我的上下文,一个用于所有POCO代码的第一个类.

我有一些业务逻辑,例如,对一个表(或几个表)的查询,这些表在几个不同的地方使用. 我应该把它放在哪里？

它不能进入POCO类,因为它连接了几个表,因此需要一个上下文.它可能会进入上下文,但是上下文会因数百个无组织的查询而变得臃肿. 所有业务逻辑都有共同的模式或安排吗？

Answer 1

Lad*_*nka 74

看起来存储库模式是一切的解决方案......存储库不是银弹!

我每天都在使用EF的存储库模式,因为几个月前我开始使用当前的项目时看起来像是推荐的解决方案.我的结论:

存储库使得与EF的交互更加困难.只需浏览与EF标签相关的问题,您就会看到必须直接在上下文,变更跟踪等方面处理哪些复杂问题.
通用存储库适用于CRUD操作,但不适用于真正的DDD方案.一旦您的存储库使用聚合根(DDD),通用方法就会失败.
单元测试根本不起作用,因为一旦你公开,你将模拟存储库并测试上层而不依赖于EF和数据库的一般想法就会失败IQueryable.Linq-to-entities只是Linq-to-objects的子集,mock不能处理引用完整性,所以我看过很多次绿色单元测试和运行时异常.EF的正确测试方法是集成测试.模拟存储库仅用于测试与数据访问无关的实际业务逻辑.如果您没有对访问或保留数据的业务方法进行集成测试,则表示您未对其进行测试.
公开像GetByXXX这样的专门方法只是退一步.大多数这些方法只使用一次.您将以与用于包装存储过程调用的存储库类似的代码结束.许多开发人员喜欢ORM只是因为他们可以避免这种僵化的架构.

EF本身已经提供了存储库模式 - DbSet并且ObjectSet是存储库,DbContext并且ObjectContext是工作单元.因此在我看来,存储库模式被过度使用.它适用于需要严格分层的大型项目,或者在为其方法添加额外逻辑的情况下.仅仅因为想要封装对EF的访问而使用存储库通常是无价值的代码,而且只是额外的复杂层.

您可以以相同的方式创建定义查询的可重用方法.

+1我曾经一直在Repository阵营中,但我同意这篇文章中陈述的所有内容 - 它只是让很多东西比它们应该的更难和更干净.由于它已经融入我目前的设计中,我现在很难放弃,但从头开始我会三思而后行. (8认同)
@Teasung:我没有处理"如果发生了什么" - 我付出的代价就是提供现在所需的功能,以便为将来可能以某种方式发生的每个场景准备我的应用程序.一旦发生这种情况,我无论如何都要做出重大改变.ORM是漏洞抽象,如果你想充分利用它的功能,你的代码中仍然会有一些隐藏的依赖(它不必引用EF,但是某些逻辑构建的方式与使用的ORM相同) ).我看到几个项目处理"如果"导致过度设计的废话,如果从未发生过. (6认同)
我在这里看到您的观点，但是您没有提供替代解决方案？服务通过规范作为约束（Lambdas）？你/你将如何设置数据访问？ (2认同)
这也是我的感觉......但是您能否详细说明如何组织您提出的建议“您可以以同样的方式创建可重用的方法来定义您的查询”。——确切地说，在哪里？ (2认同)

归档时间：	14 年，7 月前
查看次数：	7398 次
最近记录：	13 年，5 月前