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

我搜索了。。。。我看到了许多优点，但似乎所有的优点都来自于与内嵌式SQL的比较。我知道内嵌式SQL很糟糕。但是为什么要和一个坏的比较，让另一个更好呢

如果使用存储过程（可能是独占的），那么似乎没有任何优势仍然存在。存储过程在安全性、性能（如果一个ORM可以运行一个存储过程，那么这个存储过程写得不好）和一个写得好的存储过程是一个自动存储库（模式）方面提供了性能优势。存储过程可以提供更好的事务和事务隔离控制

我非常欣赏一个答案——ORM如何比使用存储过程的架构良好的应用程序更好

---

---感谢迄今为止我收到的所有答案。。。在代码中使用ORM的“动态生成的SQL”与使用“静态编写的内嵌SQL”相比，其优势似乎仍然存在。是的，它有优点。但这不是他的问题

这个问题最好表述如下：

---

如果您考虑使用存储过程来实现业务逻辑（SPS可以写得非常先进，也非常高效），那么在应用程序代码（.NET，java）中，您就有了一个非常薄的包装层，它由业务需求组织起来。我的问题是ORM是如何实现这个体系结构的（当然是一个设计良好的体系结构）。

我自己一直在寻找一个好的答案。以下是我的感受：

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

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

---

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

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

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

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

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

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

  数据集

  ）

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

ORM是一个好的体系结构吗？不。有没有系统的体系结构使用ORM会更好？当然。有没有项目因为不必要的ORM添加而受损？我猜有很多

---

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

我不认为ORM与存储过程必然是正交的。存储过程定义了面向操作的接口，但定义了ORM（即使是那些不试图将OO概念强加于关系模型的ORM）专注于在模型中而不是在表中公开数据——例如，定义良好的元组（或对象）列表。一些ORM允许使用适当的存储过程操作，而其他ORM则完全不使用存储过程。因此…“这取决于”。这不一定是因为软件工程师不熟悉SQL。我突然意识到，在很多地方，联机SQL仍然是开发应用程序时使用的数据访问方法。在这些地方，ORM工具肯定是一流的。是的。ORM的优势是与联机SQL相比较的结果。Honestly、 在现实世界中，许多应用程序，