Linq to SQL、实体框架、存储库模式和依赖注入答案

【问题标题】：Linq to SQL, Entity Framework, Repository Pattern, and Dependency InjectionLinq to SQL、实体框架、存储库模式和依赖注入
【发布时间】：2010-10-19 06:33:22
【问题描述】：

MVC and Models 上的 Stephan Walters 视频是对这个问题标题中列出的各种主题的非常好的和轻松的讨论。未回答的注释中列出的一个问题是：

如果您为 Linq2SQL 创建接口/存储库模式，即使您将类作为 toList 传递，Linq2SQLs 类是否仍会导致对 Linq 的依赖？

这可能是一个简单的答案是的，但是，您会使用什么标准机制来表示数据？

假设您有一个 Product 实体，它由三个表（价格、文本和照片）组成（您可以有不同地区的价格集、不同的本地化文本和不同的照片）。（听起来像是构建器模式）你会创建这些表格的一部分，将正确的价格、文本和照片抓取到一个列表中吗？由于 Lists 可能是专有的，您会使用 Dictionary 对象吗？

感谢您的回答。我对“标准和适当”的方式非常感兴趣，而不是 101 种可能性。

另一个简单的问题：Entity Framework 准备好用于复杂的数据库了吗？ Linq2SQL 喜欢许多 EF 不喜欢的构造。 EF 似乎需要身份字段作为主键 (HAHA)，但似乎每个演示都这样做。我想使用 EF，但总是无法正常工作，只能使用 Linq2SQL。

【问题讨论】：

标签： entity-framework interface dependency-injection

【解决方案1】：

如果您将 L2S 保留在 Repository 外观的另一侧（请记住，这就是 Repository 的全部 - 一个外观），那么您将应用程序的其余部分与 L2S 分离。这意味着存储库背后的代码的工作是将 L2S 转换为“域”对象、自定义类，然后存储库返回这些。

从这个意义上说，存储库正在返回完整形成的“产品”对象及其所有相关的价格、文本和照片数据。这称为聚合根。

列表应该没有问题，因为它们是 CLR 对象。

就高级场景的 EF 而言，我的建议还不是，因为您注意到的原因。

【讨论】：

非常有趣。到目前为止，我读了大约一半的蓝皮书。 Ron Conerys 网络广播也回顾了其中一些概念。
它是强大的东西和深水，但它的美妙之处在于你可以从 DDD 中借用而不用 100%，你可能不想第一次这样做。 John Saunders 的想法与此类似 - 在您和 L2S 之间设置一个障碍，并返回您的数据的另一种表示形式。
我个人还没有遇到 EF 无法覆盖的场景。只是那些没有“开箱即用”的东西我会说它已经准备好开展业务了。如果您想要更多功能，请查看 IdeaBlade 的 DevForce EF 产品。
不贬低 EF。它很快就会成为一个很棒的工具，但它需要再通过一次。 “开箱即用”解决方案是生产应用的圣杯。我们与 Microsoft 开发人员亲自参与了 8 周的解决方案，但从未找到答案，我们能够在一天内用 L2S 重写。因此，高级场景在 EF 中将更具挑战性。
Scott Guthrie 在 MVC 书籍第一章中对存储库模式进行了很好的解释。很有用。 MVC 是专注于 DDD 概念的好工具。

【解决方案2】：

我用来表示数据的标准机制是数据传输对象。我永远不会跨服务边界返回 LINQ to SQL 或实体框架对象，并且我会犹豫跨任何层边界返回它。这是因为这些对象会序列化依赖于实现的数据。

【讨论】：

是的，这应该是公认的答案。 DTO 是允许通过 Repository 方法从您的 ORM 策略和 UI 绑定中抽象出来的方法。
@jwendl - 您似乎对我的回答不满意，所以我很好奇，作为自查，我的回答与您的回答有何冲突？您是否通过存储库返回“DTO”或域聚合只是使用问题。如果您只需要一个 DTO，那很好，但我在这里考虑的是领域驱动设计，它非常适合 MVC。