我搜索了....我看到了很多优点，但似乎所有优势都来自于对内嵌SQL的比较。我知道内联SQL很糟糕。但为什么要比较糟糕的那个更好地展示另一个呢？
如果使用存储过程（可能是唯一的），似乎没有任何优势仍然存在。存储过程肯定在安全性，性能方面提供了性能优势（如果ORM可以超过存储过程，那么存储过程写得很糟）并且编写良好的存储过程是自动存储库（模式）。存储过程绝对可以提供更好的事务和事务隔离控制。
我真的很感激答案 - 使用存储过程，ORM如何优于使用良好架构的应用程序。
---感谢我到目前为止收到的所有答案......似乎优势仍然来自使用ORM的“动态生成的SQL”与在代码中使用“静态编写的内联SQL”进行比较。是的，它有优势。但这不是他的问题。
问题更好地说明如下：
如果您考虑使用存储过程来实现业务逻辑（SP可以编写得非常高级，而且效率非常高），那么在应用程序代码（.NET，JAVA）中，您有一个非常薄的存储层包装器按业务需要组织的程序。我的问题是ORM如何超越这种架构（当然是一个精心设计的架构）。
答案 0 :(得分：0)
我一直在寻求一个好的答案。以下是我的感受：
1）ORM提高了开发人员的工作效率 - 将域类映射到数据库更容易。 2）存储过程可能包含业务逻辑 - 很难对它们进行测试。这主要是因为缺乏工具/模拟框架。 3）ORM框架是经过测试的框架，它们为您提供开箱即用的缓存功能 - 无需重新发明轮子 - 在大多数应用程序中我看到哪些不使用任何ORM功能最终编写内部数据层ORM开箱即用。
话虽如此 - ORM确实增加了一些开销，并且它要求开发人员意识到一个新的平台 - 编写高效的映射随着实践而来，所以有一个学习曲线。
在现代设置中，网络带宽并不像快速开发和高质量（经过良好测试）的代码那样珍贵。我想这使得ORM非常适合数据库驱动的应用程序。
答案 1 :(得分：0)
ORM工具可以在OO环境中开发数据库和模型之间的抽象层。这一层的主要优点是不熟悉SQL的开发人员可以使用该模型。
答案 2 :(得分：0)
ORM是一种工具，可用于构建您称之为“架构良好的系统”。我们的想法是，当您使用非关系语言进行开发时，SQL /存储过程提供的关系操作集与您用于构建应用程序其余部分的语言之间将存在impedance mismatch。
对于使用面向对象语言（无论是C ++，C＃还是Java）的开发人员，在将复杂关系模式映射到富域模型时需要考虑许多因素。当然可以在您自己的代码中执行所有这些映射，但是当您在OO和Relational范例之间的“无人区域”中的交互变得越来越复杂时，ORM引擎和相关工具就越有用。
在规划地图图层时需要考虑一些因素：
DataSet）？另一个考虑因素，特别是在团队中工作时，是当手动执行与域图层映射的关系时，开发人员编写映射的方式可能会有很多变化。这可能导致难以检测的不一致，重叠和间隙。 ORM的选择（特别是一个众所周知的/稳固建立的ORM）可以对解决方案产生巨大的（希望是积极的）影响，并且围绕ORM的预先存在的社区将塑造你如何设想映射层（你会发现例如，Spring.NET和Entity Framework用户之间存在重大的文化差异。
ORM是否构成了良好的架构？不是。有哪些系统的架构会因ORM而变得更好？肯定。是否存在因不必要的ORM添加而导致项目瘫痪的项目？我猜这里有很多。
我建议从不同角度处理此问题，并将其应用于您正在处理的特定应用程序。使用ORM可能解决的SQL和/或存储过程，您是否有任何痛点？您是否看到任何风险或对引入ORM可能导致的问题有任何疑虑？只有通过权衡这些问题的答案，您才能确定ORM是否适合任何给定的解决方案。