除了将关系数据转换为对象模型外，ORM还具有其他作用，例如：
- 延迟加载
- 自动变化检测
- 交易次数
但是，使用Repository模式将ORM的DTO转换为Domain Models时，会发生以下情况：
- 无法使用延迟加载的好处，因为我需要填充整个域模型，并且存储库不知道域需要什么数据。
- 由于域模型不是来自ORM世界，所以ORM无法检测到更改。
- 由于缺乏对ORM的域知识，因此一次无法进行多次交易
问题1：在领域驱动的设计方案中，我是否可以在懒惰加载，事务和自动更改检测的全部好处上缺少一些差距？还是这些优势是DDD以外的其他方法（例如Active Record）带来的更多收益？
问题2：为什么在DDD书籍中如此提及orm？仅针对关系域模型和延迟加载，事务和变更检测进行全面论述
某些平台采用了代码优先的方法，这是一种改善这些问题的方法，但是，此功能并不总是在许多环境中存在，或者根本无法使用（例如，在旧数据库中），因此它不是解决方案。
我已经思考了一段时间，如果要从ORM中删除变更跟踪，那么开发人员将会发现其中的价值要小得多。
延迟加载永远不会发生。聚合始终始终完整加载。如果您发现自己需要延迟加载机会，那就是您正在查询域模型。这是您不应该做的事情。为此使用一个简单的查询层/读取模型。
事务确实是数据库关注的问题，不会直接影响DDD。聚合确实代表了一个一致性边界，因此数据库事务自然是合适的，但那才是结束。
您仍然可以将ORM工具与DDD一起使用，但是获得的里程数可能会减少。我根本不喜欢ORM，如果在这个问题上我有任何选择，我就根本不使用它们。映射实际上并不需要那么多的工作，而且如果在自定义映射器类中完成映射，则它以某种语言速度而不是某些代理机制运行。
我见过一些实例，例如，使用ORM直接保留域对象。但是，如果我必须使用某个属性来标记任何东西，或者甚至更改我的设计，在其中我必须以某种特定方式实现某些方法virtual甚至构造某些类，那么我就不再认为自己的域是持久性的无知，那就是我真的想要（PI）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句