orm - 代码生成器还是 ORM？

Question

你对数据访问层有什么建议？使用 Entity Framework 和 Hibernate OR 代码生成器(如 Subsonic、.netTiers、T4 等)等 ORM？

Answer 1

对我来说，这很简单，你生成代码。

我将在这里稍微偏离主题，因为有一个更大的潜在谬误在起作用。谬论是这些 ORM 框架解决了对象/关系阻抗不匹配问题。这种说法是赤裸裸的谎言。

我发现解决对象/关系阻抗不匹配的最佳方法是专门使用 OOP 并使用对象数据库，或者专门使用关系数据库的习语而忽略 OOP。

对我来说，“一切都是一张 table ”的抽象比“一切都是一个类”的抽象要强大得多。当您编码到数据库而不是对象模型时，它需要更少的代码，更少的智力工作并导致更快的代码。

对我来说，这似乎很明显。如果您的应用程序是数据驱动的，那么您的代码肯定也应该是数据驱动的吗？然而，要说这是非常有争议的。

这里的核心问题是，当与数据库结合使用时，OOP 变成了一个真正有漏洞的抽象。当您看到代码在数据库中生成的流量时，用 OOP 的习惯用法编写时看起来非常合理的代码看起来完全疯狂。当这种困惑成为性能问题时，OOP 是第一个受害者。

真的没有办法解决这个问题。数据库处理数据集。 OOP 专注于类的实例。两个人想结婚，终究会以离婚收场。

所以为了回答你的问题，我相信你应该生成你的类并尝试让它们尽可能地映射底层数据库结构。