做 DDD 时是否应该在 POCO 类上使用 DI？答案

【问题标题】：Should one use DI on POCO classes when doing DDD?做 DDD 时是否应该在 POCO 类上使用 DI？
【发布时间】：2010-03-03 09:09:15
【问题描述】：

假设我有一个很好的域模型，在需要时使用（构造函数）DI。现在我希望能够坚持这个模型，所以我开始添加基础设施（实体框架）来做到这一点。现在发生的事情是持久性框架应该能够使用您的 IoC 容器初始化您的类型。

也许这是可能的，也许不是。无论如何，我现在想知道的是；在你的 POCO 课程上使用 DI 通常吗？如果是，我如何让 Entity Framework 使用我最喜欢的 IoC 容器（在我的例子中为 NInject）来构造我的类。

【问题讨论】：

【解决方案1】：

使用 IoC 容器来构造从数据库中获取的实体是非常好的，我在我的项目中这样做。

ORM 不应支配您的设计。 NHibernate 可以与 IoC Container 一起玩得很好，我不知道 EF 但我怀疑它不会。如果我是你，我会把 EF 换成 NHibernate，或者其他任何东西。

【讨论】：

【解决方案2】：

这是 DDD 社区中的一种宗教观点：我应该将服务注入我的实体吗？这真的是一个你必须自己回答的问题。我不会告诉你我的想法，因为它是高度相关的——我的想法会根据几个因素而变化。

我确实认为您需要花几个小时深入挖掘 ddd list 的档案，以找到适合您的答案。

【讨论】：

【解决方案3】：

如果您想使用 EF，请考虑使用 EF4，您确实可以在其中使用 POCO 模板。您可以围绕您的 POCO 类实现存储库，并且您将能够在将 IoC 与另一个 ORM 一起使用时使用它。拥有 POCO 后，一切都与应用架构分层有关。

看看这个演练：

【讨论】：

这正是我正在使用的 :-) 也使用存储库，但我的对象仍然由 EF 实例化。如果我想使用延迟加载（需要代理类），我需要使用 EF 的context.CreateObject。此方法是非虚拟的，我没有看到任何其他扩展点。
你不需要使用上下文。如果您将 POCO 类的每个属性都标记为虚拟，那么 EF 将执行一个巧妙的技巧。它将代表 POCO 类启动代理 EntityObjects，该类将执行 EntityObjects 已经知道如何做的事情——通知属性和关系更改的上下文以及允许延迟加载。