问为什么不在DDD中使用ORM呢？

EN

为了明确起见，我说“在F#中，我们倾向于不使用对象-关系映射器( ORM )”，但不是因为任何验证问题，而是因为像实体框架这样的大型ORM是高度面向对象的(惊讶！)它并不总是与功能范式很好地结合在一起。相反，F#ers要么使用类型提供程序，要么使用更简单的库(如Dapper )。

在“使用关系数据库”一章中，我确实说过，您可以以两种不同的方式处理数据库：

• 作为不受信任的源，在这种情况下，您按照通常的方式进行验证(例如，对于来自JSON的数据也是如此)。
• 作为受信任的源，在这种情况下，如果数据是坏的，则不进行验证并抛出异常。

应用哪种情况取决于数据库是否与其他应用程序共享，如何设计数据库等等。

最新情况:我认识到以下句子可能会被误解：

难道我们不能只使用像实体框架或NHibernate这样的东西来自动完成所有这些映射吗？如果您想要确保域的完整性，则答案是否定的。

我的意思是，通过ORM将域模型直接转换到数据库意味着，您将失去域类型的复杂性--“使非法状态无法表示”的设计方法，这是我专门讨论的一章。这是因为ORMs不知道如何处理带有约束、复杂选择类型等的单用例联合。

相反，我建议您将域对象转换为专门为持久性设计的类型( " DTO ")，然后使用该DTO进行持久化，而不是使用域类型。要存储/加载DTO，您当然可以使用EF或NHibernate，但是当您以这种方式使用它时，您不会从中获得太多的价值，因此通常使用类型提供程序或像Dapper这样的轻量级映射程序比较容易。

如果你读了这本书的下一段，它会说：

使用类型提供程序而不是典型的运行时库的特殊之处在于，SQL类型提供程序将在编译时创建与SQL查询或SQL命令匹配的类型。如果SQL查询不正确，您将得到编译时错误，而不是运行时错误。如果SQL是正确的，它将生成一个与SQL代码的输出完全匹配的F#记录类型。

因此，这种方法似乎提供了一些与C#中的静态类型相同的保证。也就是说，如果您的类型不对齐，您将在编译时得到一个错误。