使用 ORM 工具（框架）有什么好处？

Question

我搜索了...。我看到了许多优点，但似乎所有优点都来自与内联 SQL 的比较。我知道内联 SQL 不好。但是为什么要与一个坏的比较来展示另一个更好呢？

如果使用存储过程（可能只使用存储过程），似乎没有任何优势仍然存在。存储过程在安全性、性能方面无疑提供了性能优势（如果 ORM 可以运行存储过程，则存储过程编写得不好），编写良好的存储过程是自动存储库（模式）。存储过程绝对可以提供更好的事务和事务隔离控制。

我非常感谢您的回答——ORM 如何优于使用存储过程的架构良好的应用程序。

---

--- 感谢到目前为止我收到的所有答案......似乎优势仍然来自在代码中使用 ORM 的“动态生成的 SQL”与使用“静态编写的内联 SQL”进行比较。是的，它有优势。但这不是他的问题。

这个问题最好表述如下：

如果您考虑使用存储过程来实现您的业务逻辑（SP 可以编写得非常高级，也非常高效），在应用程序代码（.NET、JAVA）中，您有一个非常薄的存储层包装器按业务需要组织的程序。我的问题是 ORM 如何胜过这种架构（当然是精心设计的架构）。

Answer 1

ORM 工具可以在 OO 环境中开发数据库和模型之间的抽象层。该层的主要优点是不熟悉 SQL 的开发人员可以使用该模型。

Answer 2

我自己一直在寻找一个好的答案。以下是我觉得与众不同的地方：

1) ORM 提高了开发人员的工作效率——将域类映射到数据库更容易。 2）存储过程可能包含业务逻辑 - 很难测试这些。这主要是因为缺乏工具/模拟框架。 3) ORM 框架是经过测试的框架，它为您提供开箱即用的缓存等功能 - 无需重新发明轮子 - 在我见过的大多数应用程序中，不使用任何 ORM 功能最终会编写内部数据层，其中 ORM开箱即用。

话虽如此 - ORM 也确实增加了一些开销，并且它要求开发人员了解新平台 - 编写有效的映射需要实践，因此有一个学习曲线。

在现代设置中，网络带宽并不像快速开发和高质量（经过良好测试）的代码那么宝贵。我想这使得 ORM 非常适合数据库驱动的应用程序。

Answer 3

ORM 是一种工具，可用于构建您所谓的“架构良好的系统”。这个想法是，当您使用非关系语言进行开发时，在 SQL/存储过程提供的关系操作集和您用于构建应用程序其余部分的语言之间会有一个impedance mismatch。

对于使用面向对象语言（无论是 C++、C# 还是 Java）的开发人员，在将复杂的关系模式映射到富领域模型时需要考虑很多因素。当然可以在您自己的代码中执行所有这些映射，但是随着您在 OO 和关系范式之间的这个“无人区”中的交互变得越来越复杂，ORM 引擎和相关工具就会变得越有用。

规划映射层时的一些注意事项：

• 您需要管理单表还是多表继承？
• 您想利用延迟加载吗？
• 您想手动保持类和表同步，还是计划使用工具生成每个表的类（例如使用DataSet）？

另一个考虑因素，尤其是在团队中工作时，是当手动执行与域层的关系映射时，开发人员编写映射的方式可能会有很大的变化。这可能导致难以检测的不一致、重叠和差距。选择一个 ORM（尤其是一个众所周知的/稳固建立的 ORM）可以对解决方案产生巨大的（希望是积极的）影响，并且围绕该 ORM 的预先存在的社区将影响您对映射层的构想（您会发现例如，Spring.NET 和 Entity Framework 用户之间存在显着的文化差异）。

ORM 是否构成良好的架构？不。有没有一些系统的体系结构使用 ORM 会更好？确实。是否有项目因不必要地添加 ORM 而瘫痪？我猜有很多。

我建议从不同的角度来解决这个问题，并将其应用于您正在处理的特定应用程序。使用 ORM 可以解决的 SQL 和/或存储过程是否有任何痛点？您是否看到任何风险或担心引入 ORM 可能导致的问题？只有权衡这些问题的答案，您才能确定 ORM 是否适合任何给定的解决方案。