.net - 从组织上讲，在使用 Entity Framework Code First 时，我应该将常见查询放在哪里？

Question

我正在使用 EF 4.1 Code First 布置一个新的数据层，从旧的自制数据层迁移。

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

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

它不能进入​​ POCO 类，因为它连接了几个表，因此需要一个上下文。它可以进入上下文，但该上下文会因数百个杂乱无章的查询而变得臃肿。 所有业务逻辑是否有共同的模式或安排？

Answer 1

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

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

存储库使与 EF 的交互更加困难。只需浏览与 EF 标签相关的问题，您就会看到必须直接在上下文、变更跟踪器等上处理哪些复杂性。

通用存储库适用于 CRUD 操作，但不适用于真正的 DDD 场景。一旦您的存储库使用聚合根 (DDD)，通用方法就会失败。

单元测试根本不起作用，因为一旦暴露 IQueryable，您将模拟存储库并测试您的上层而不依赖于 EF 和数据库的一般想法就会失败。 . Linq-to-entities 只是 Linq-to-objects 的子集，我多次看到绿色单元测试和运行时异常，mock 不处理参照完整性。使用 EF 的正确测试方法是集成测试。 Mocking repository 仅用于测试与数据访问无关的真实业务逻辑。如果您没有对访问或持久化数据的业务方法进行集成测试，则您没有对其进行测试。

公开像 GetByXXX 这样的专门方法只是退后一步。大多数这些方法只使用一次。您将以类似于用于包装存储过程调用的存储库的代码结束。许多开发人员喜欢 ORM 只是因为他们可以避免这种僵化的架构。

EF 本身已经提供存储库模式 - DbSet和 ObjectSet是存储库和 DbContext和 ObjectContext是作品单元。所以在我看来，存储库模式被过度使用了。它在需要严格分层的大型项目中或在为其方法放置附加逻辑的情况下非常有用。仅仅因为您想包装对 EF 的访问而使用存储库通常是无值(value)的代码，并且只是额外的复杂层。

您可以以同样的方式创建可重用的方法来定义您的查询。