使用ORM工具（框架）有哪些优势？

Question

使用ORM工具（框架）有哪些优势？

3

我搜索了一下....我看到很多优点，但似乎所有的优点都是与内联SQL进行比较得出的。我知道内联SQL是不好的。但为什么要拿一个不好的东西来比较，以显示另一个更好呢？

如果使用存储过程（可能是唯一的），似乎所有的优点都不存在了。存储过程在安全性、性能（如果ORM可以跑赢存储过程，那么存储过程就写得很糟糕）方面确实提供了性能优势，并且写得好的存储过程是自动存储库（模式）。存储过程肯定可以提供更好的事务和事务隔离控制。

我真的很感激一个答案——ORM如何优于使用存储过程的良好架构应用程序。

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

问题更好地陈述为以下内容：

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

- Song Li

我不认为ORM必然与SPROCs正交。 SPROCs定义了一个面向操作的接口，但ORM（即使那些不试图将OO概念强加于关系模型的ORM）专注于以表之外的模型公开数据 - 例如，一组定义良好的元组（或对象）。一些ORM将允许使用适当的SPROC操作，而其他ORM则完全避免使用SPROCs。所以...“这取决于”。 - user166390

3个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Srikanth Venugopalan · Answer 1

我一直在寻找一个好的答案。以下是我认为有所不同的原因：

1）ORM提高了开发人员的生产力 - 映射领域类到数据库更容易。 2）存储过程可能包含业务逻辑 - 很难测试这些。这主要是由于缺乏工具/模拟框架。 3）ORM框架是经过测试的，可以为您提供诸如缓存之类的功能 - 无需重新发明轮子 - 在大多数应用程序中，我看到没有使用任何ORM功能的应用程序最终编写内部数据层，而ORM则提供了这个功能。

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

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

- Ilya Lakhin · Answer 2

ORM工具使得在面向对象的环境中开发数据库和模型之间的抽象层成为可能。这个层的主要优势是那些不熟悉SQL的开发人员也可以使用模型进行工作。

- Ethan Cabiac · Answer 3

ORM是一个工具，可以用来构建所谓的“良好架构系统”。其理念是，在非关系型语言下进行开发时，SQL /存储过程提供的关系操作集与您用于构建应用程序其余部分的语言之间存在阻抗不匹配。

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

一些在规划映射层时需要考虑的问题如下：

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

另一个需要考虑的问题，特别是在团队合作时，手动执行领域层映射时，开发人员编写映射的方式可能会有很大的差异。这可能会导致不一致性、重叠和难以检测的间隙。选择ORM（特别是一个知名/稳定的ORM）可以对解决方案产生巨大的（希望是积极的）影响，ORM周围的社区将塑造您对映射层的构思（例如，您会发现Spring.NET和Entity Framework用户之间存在显着的文化差异）。

ORM是否能够构建良好的架构？不是。有没有系统的架构会因为使用ORM而变得更好？肯定有。有没有因为不必要地添加ORM而导致项目瘫痪的情况？我猜可能有很多。

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