带有ORM的丰富域模型

Question

我似乎错过了一些东西,谷歌的广泛使用无助于提高我的理解......
这是我的问题:
我喜欢以持久性无知的方式创建我的域模型,例如:

1. virtual如果我不需要,我不想添加.
2. 我不喜欢添加默认构造函数,因为我喜欢我的对象总是完全构造.此外,在依赖注入的上下文中,对默认构造函数的需求是有问题的.
3. 我不想使用过于复杂的映射,因为我的域模型使用ORM不易支持的接口或其他构造.

对此的一个解决方案是具有单独的域对象和数据实体.使用存储库模式可以轻松地检索构造的域对象,并从ORM返回的数据实体构建域对象.使用AutoMapper,这将是微不足道的,而不是太多的代码开销.

但是这个方法有一个很大的问题:似乎我不能真正支持延迟加载而不自己编写代码.另外,对于相同的"事物",我会有很多类,特别是在WCF和UI的扩展上下文中:

1. 数据实体(映射到ORM)
2. 领域模型
3. WCF DTO
4. 查看模型

所以,我的问题是:我错过了什么？这个问题一般如何解决？

更新:
到目前为止的答案表明我已经担心的事情:看起来我有两个选择:

1. 在域模型上做出妥协以匹配ORM的先决条件,从而具有ORM泄漏到的域模型
2. 创建许多其他代码

更新:
除了接受的答案,请参阅我的答案,了解我如何为我解决这些问题的具体信息.

Answer 1

简而言之 - 它没有解决

(这里有额外无用的字符来发布我真棒的答案)

Answer 2

我想问一下,匹配ORM的先决条件必然是"妥协".然而,从高度SOLID,松散耦合的架构的角度来看,其中一些是公平的.

ORM框架存在的唯一原因; 采用您实现的域模型,并将其保存到类似的数据库结构中,而不必实现大量容易出错,几乎不可能的单元测试SQL字符串或存储过程.他们还可以轻松实现延迟加载等概念; 在需要该对象之前的最后一分钟给对象加水,而不是自己构建一个大的对象图.

如果您想要存储过程,或者需要它们并且需要使用它们(无论您是否想要),大多数ORM都不是正确的工具.如果您有一个非常复杂的域结构,以至于ORM无法映射字段与其数据源之间的关系,我会严重质疑您使用该域和该数据源的原因.如果您想要100%POCO对象,而不了解后面的持久性机制,那么您可能最终会围绕ORM的大部分功能进行最终运行,因为如果域没有虚拟成员或子集合可以用代理替换,然后你被迫加载整个对象图(如果你有一个庞大的相互关联的对象图,这可能是不可能的).

虽然ORM在域设计方面确实需要持久性机制领域的一些知识,但ORM仍然会产生更多的SOLID设计,即IMO.没有ORM,这些是您的选择:

• 滚动您自己的存储库,其中包含一个方法,用于生成和保留域中的每种类型的"顶级"对象("上帝对象"反模式)
• 创建每个处理不同对象类型的DAO.这些类型要求您对ADO DataReader和对象之间的get和set进行硬编码; 在一般情况下,映射大大简化了过程.DAO也必须彼此了解; 要保留发票,您需要发票的DAO,它还需要为InvoiceLine,Customer和GeneralLedger对象提供DAO.并且,必须在所有这些中内置一个通用的,抽象的事务控制机制.
• 设置一个ActiveRecord模式,其中对象可以自行保存(并将更多有关持久性机制的知识放入您的域中)

总的来说,第二个选项是最SOLID,但更多时候它变成了野兽和三分之二的维护,特别是在处理包含反向引用和循环引用的域时.例如,对于快速检索和/或遍历,InvoiceLineDetail记录(可能包含运输说明或税务信息)可能直接引用Invoice以及它所属的InvoiceLine.这创建了一个3节点循环引用,要求O(n ^ 2)算法检测已经处理了对象,或者需要关于反向引用的"级联"行为的硬编码逻辑.我以前必须实施"图形步行者"; 相信我,如果有其他方式做这项工作,你不想这样做.

因此,总而言之,我认为,鉴于域名足够复杂,ORM是所有邪恶中最少的.它们封装了很多关于持久性机制的非SOLID,并将关于其持久性的域的知识减少到分解为简单规则的非常高级的实现细节("所有域对象必须将所有公共成员标记为虚拟").