ORM是反模式吗？[关闭]

我与一位同事就ORM及其优缺点进行了非常刺激和有趣的讨论。我认为，ORM仅在极少数情况下才有用。至少以我的经验。

但是我现在不想列出自己的论点。所以我问你，你对ORM有什么看法？优点和缺点是什么？

尝试从面向对象的角度访问关系数据库时，存在一系列相当大的概念和技术难题。这些困难统称为 对象关系阻抗不匹配，而相关的Wikipedia文章则非常有用。这篇文章指出了很多，在这里我没有任何明智的描述方式。只是为了给您一个大致的概念，它们被分类为：

• 不匹配
  • 面向对象的概念
  • 数据类型差异
  • 结构和完整性差异
  • 操纵差异
  • 交易差异
• 解决阻抗失配
  • 最小化
  • 替代架构
  • 补偿金
• 争夺
• 哲学差异

我认为，如果您花时间阅读本文，您将会理解，有时将ORM描述为反模式实际上是不可避免的。这两个领域的差异如此之大，以至于在某种程度上，将一种模式视为另一种模式的方法默认都是一种反模式，因为反模式是一种违反领域原理的模式。

但是我不认为该术语适用于本质上充当两个截然不同的领域之间的桥梁的任何事物。将模式标记为反模式仅在其范围内有意义。因此，它是否是反模式的问题是无关紧要的。

但这有用吗？是的，ORM是那里最有用的反模式之一。您将理解为什么只有在遇到必须在项目中交换数据库的实际情况时才这样做。甚至升级到同一数据库的另一个版本。ORM是其中之一，您只有在真正需要它们时才完全了解。

当然，ORM非常有用，非常有用。如果您认为它以某种方式取代了对您正在使用的数据库的所有知识的了解，那么它就会再度引起您的注意。硬。

最后，让我无耻地插入另一个答案，即有关“ ActiveRecord模式是否遵循/鼓励SOLID设计原则？”的问题。这个问题，对我来说，比“是反模式”要重要得多。

这类似于询问“电钻是否是反模式？”。ORM在我的工具箱中占有一席之地，减少了我的样板代码，并且在必要时我仍然可以使用自定义SQL。因此，如果它是反模式，它将与哪种模式相对？

我的答案是不，有很多成熟的ORM使您的生活变得更加轻松，并使您的代码更易于理解。无论如何，这意味着您不需要了解SQL，恰恰相反。

我会毫不犹豫地将其称为“反模式”，它最初被Martin Fowler称为模式，此后几乎被所有现代编程语言所接受。（请参阅ActiveRecord上的Wikipedia文章。）

一个好的ORM可以导致一个项目中更少的代码（和更少的重复），并且与原始代码数量一样，与bug的相关性也不高。

ORM通常设计为处理使用数据库的最常见用例。复杂的查询可能仍需要显式编写。但是我强烈不建议为每次数据库交互编写显式查询。在大多数情况下，这是浪费时间。

使用ORM而不是学习SQL是一个非常糟糕的主意。如果您不完全了解所生成的SQL的类型，如果您不了解N + 1问题以及如何进行优化，那么它肯定会带来弊大于利的结果。不过，我觉得使用ORM可以提高工作效率。我更喜欢Rails ActiveRecord，它不会试图假装没有数据库，并且在您只需要编写SQL时也不会妨碍您。我确实担心，尽管有些人可能对他们所看到的习语过于深入地信任，却没有对他们正在做的事情有深入的了解。

我的经验：我将NHibernate与Linq2NHibernate一起使用。

优点：

• 它摆脱了“魔术弦”，或者至少提供了一次唯一的放置它们的地方
• 它使我可以一直在OO模式下工作
• 该代码更易于阅读
• 建立在最上面的代码更容易更改
• 它允许您换出实际的关系数据库而无需维护2个单独的存储库（很少做，但这是您需要的一大好处）。

缺点：

• 该代码更难编写，因为
• 这还不够抽象-您仍然必须非常熟悉它在后台所做的工作

我会说，这没有兑现大多数人最初希望的承诺。我不会怪别人说这是反模式。以我为例，我仍然需要对SQLite数据库进行集成测试，以确保我的Linq2NHibernate查询确实有效。所以说真的，如果您仍然要对真实的关系数据库进行集成测试，则可以消除“魔术字符串”的问题。

如果我要开始一个新项目，则不确定是否要使用ORM。我可能会，但是我不能肯定地说你应该。我会说这就像为您的项目选择C ++或Java / .NET之间的区别：您是否需要较低级别的灵活性，或者是较高级别的（应该）更多？有生产力吗？正常的答案是在尽可能高的水平的工作，因为你可以逃脱。这通常意味着使用ORM。

ORM的优势在于，它允许您使用面向对象的技术对应用程序行为进行建模。在经过精心设计的世界中，您拥有应用程序的一层，业务的语言与开发团队的语言完全一致。如果明智地使用ORM，那么ORM就是一个促成因素。

弱点是实际上真正获得面向对象编程的人数很少。很多人写意大利面条和肉丸，而高度耦合的对象却几乎没有自己的行为，而实际行为最终出现在丑陋的8000行“服务”和“经理”类中，并且代码通常是如此复杂，以至于每个人都害怕进行更改，因为他们不知道会有什么副作用。

另外，很多人并没有真正获得关系模型。ORM不会帮助他们获得它，也不会通过抽象出关系模型来帮助他们。它只允许您尽早专注于域层，并在开始过于担心数据库设计之前就做好了准备。如果应用得当，借助明智的模式迁移工具，ORM可以帮助您防止代码积聚。

我构建的应用程序中，ORM使应用程序代码保持简单，易读和可测试，并具有合理的性能。我还维护了一些应用程序，其中模式被滥用，代码混乱，不可测试，运行缓慢且脆弱。事实证明，ORM本身与此无关，除了遗留的工程团队写了不好的代码而不是对应用程序域建模的糟糕代码，而忽略了所有的错误的服务层代码，而不是编写不好的代码对应用程序域进行建模。他们的ORM可以为他们提供的价值。

ORM不会使您变得更聪明，但是在合适的开发人员的手中，ORM可以导致更易于维护和更高质量的代码。

答案可能与您的问题相反：将应用程序数据存储在关系数据库以外的其他内容中是个好主意吗？您要消除哪些问题，您还会遇到哪些其他问题？您能否生活在无法轻松地交叉引用数据（联接）或基于多个条件快速筛选出所需记录的能力？您是否不需要可靠的交易支持（假设您的替代品没有）？并非所有应用程序都需要始终一致且完整的数据存储。

我认为这里真正的反模式可能是在您不需要关系数据库时使用关系数据库。如果需要一个，则需要ORM，这绝对不是反模式。

ORM是一个工具。像所有工具一样，如果使用得当，它们也可以很好地工作。如果使用不当，则需要使用更大的锤子和胶带。

对于我正在从事的当前项目，该项目将由非开发人员（准确地说是机械工程师）维护，因此需要简单易懂。该小组有预算聘请开发商需要几年的时间（假定下一任总统不会废除所涉机构），因此未来的维护能力是我们考虑的主要因素。