domain-driven-design - 你如何处理 DDD 和 EF4

Question

我在尝试使用 EF4(在 ASP MVC2 上下文中)应用 DDD 时遇到了几个问题。您的建议将不胜感激。

首先，我开始使用 POCO 是因为在很多情况下对 ObjectContext 的依赖不是很舒服。

去 POCO 解决了一些问题，但体验不是我用 NHibernate 所习惯的。

我想知道是否可以使用设计器，不仅可以生成实体，还可以生成值对象(ComplexType？)。如果我的意思是值对象是一个没有任何设置属性的 ctor 的类(需要 T4 修改？)。

我发现向贫血实体添加行为的唯一方法是创建部分类来扩展 edmx 生成的类。我对这种方法不满意。

我不知道如何用一个 edmx 创建多个存储库。现在我正在使用部分类来对每个聚合的方法进行分组。每个组实际上都是一个存储库。

最后一个问题是关于 IQueryable 的。它应该暴露在存储库之外吗？如果我引用 ble 书，存储库应该是一个执行单元，不应该公开 IQueryable 之类的东西。你怎么认为 ？

谢谢你的帮助。

托马斯

Answer 1

使用 POCO 没问题，但请注意 EntityObject不需要 ObjectContext .

是的，复杂类型是值对象，是的，您可以在设计器中生成它们。选择一个实体的几个属性，右击，选择refactor into complex type。

我强烈建议将业务方法放在它们自己的类型中，而不是放在实体上。如果您必须维护它们，“贫血”类型可能是一个问题，但是当它们被编码生成时，它们几乎不是维护问题。将业务逻辑与实体类型分开允许您的业务规则和数据模型独立发展。是的，如果必须混合这些问题，则必须使用部分类，但我认为将模型和规则分开并不是一件坏事。

我认为存储库应该公开 IQueryable ，但是您可以很好地说明域服务不应该这样做。人们经常尝试将他们的存储库构建到域服务中，但请记住，存储库的存在只是为了抽象出持久性。安全性等问题应该在域服务中，您可以证明拥有 IQueryable给了消费者太多的权力。