代码生成器 vs ORM vs 存储过程

Question

在哪些领域中，这些软件架构中的每一个都会有优劣之处？

哪些关键要求会促使您选择其中之一？

请假设您有可以编写良好的面向对象代码和良好的数据库开发的开发人员。

另外，请避免神圣战争 :) 所有三种技术都有优缺点，我想知道在哪里使用哪种技术最合适。

- Sklivvz

Answer 1

这些工具都提供不同的抽象层次以及不同的行为覆盖点。这些都是架构选择，并且所有架构选择都依赖于技术、控制和组织之间的权衡，无论是应用程序本身还是它将部署的环境。

• 如果你正在处理一个DBA“统治全局”的文化，那么基于存储过程的架构将更容易部署。另一方面，管理和版本控制存储过程可能会非常困难。

• 代码生成器在使用静态类型语言时表现出色，因为您可以在编译时而不是运行时捕获错误。

• ORM适用于集成工具，在这些工具中，您可能需要根据安装情况处理不同的RDBMS和模式。更改一个映射，您的应用程序就可以从适用于Oracle上的PeopleSoft变为适用于SQL Server上的Microsoft Dynamics。

我见过使用生成的代码与存储过程进行接口的应用程序，因为可以调整存储过程以避免代码生成器的限制。

最终，唯一正确的答案取决于您要解决的问题以及解决方案需要执行的环境。其他任何答案都是在争论“potato”正确的发音。

- W. Craig Trader

---

我知道这是一个旧帖子，但 ORM 的一个优点是它们通常可以自动管理缓存，而如果您想使用存储过程来做到这一点，则必须手动完成，这是一个麻烦事。 - Augusto

Answer 2

我想加上我的两分钱:

存储过程

• 能够轻易进行优化
• 抽象出核心业务规则，增强数据完整性
• 提供良好的安全模型（不需要授予前端数据库用户读写权限）
• 在许多应用程序访问相同数据时发挥作用

ORMs

• 让您只专注于领域，并采用更“纯粹”的面向对象开发方式
• 当您的应用程序必须跨数据库兼容时发挥作用
• 当您的应用程序主要由行为而不是数据驱动时发挥作用

代码生成器

• 为您提供与ORM类似的好处，但维护成本更高，但可定制性更好。
• 通常优于ORM，因为ORM往往以编译时错误换取运行时错误，这通常应该避免

- Sklivvz

Answer 3

我认为每件事情都有利弊，很多取决于你的架构。话虽如此，我尽量在有意义的地方使用ORM。很多功能已经存在，通常它们有助于防止SQL注入（而且有助于避免重复发明轮子）。

请参阅有关此主题的其他两篇文章（动态SQL vs存储过程vs ORM），以获取更多信息

动态SQL vs存储过程
哪个更好：Ad hoc查询还是存储过程？

ORM vs存储过程
为什么NHibernate生成的参数化SQL与存储过程一样快？

- Ryan Lanciaux

Answer 4

ORM和代码生成器在一侧，而存储过程则在另一侧。通常，在绿地项目中使用ORM和代码生成器更容易，因为您可以根据创建的领域模型来定制数据库架构。在遗留项目中使用它们要困难得多，因为一旦软件以“数据优先”的思维方式编写，就很难用领域模型包装它。

话虽如此，这三种方法都有价值。存储过程可能更容易优化，但可能会诱人将业务逻辑放入其中，这些逻辑可能在应用程序本身中重复。如果您的架构与ORM的概念匹配，则ORM可以很好地工作，但如果不匹配，则可能很难自定义。代码生成器可以是一个不错的折中方案，因为它们提供了ORM的一些好处，但允许自定义生成的代码--但是，如果您习惯于修改生成的代码，那么您就会面临两个问题，因为每次重新生成时都必须进行修改。

没有一个真正的答案，但我更倾向于ORM方面，因为我认为以对象为中心的思维方式更有意义。

- nkohari

Answer 5

你忘记了一个重要的选项，它应该有自己的类别：混合数据映射框架，例如iBatis。

我很满意iBatis，因为它让你的面向对象代码保持面向对象的特性，让你的数据库保持关系型的特性，并通过添加第三个抽象层（对象和关系之间的映射层）来解决阻抗不匹配问题，而不是试图将一种范式强制适应另一种范式。

- Kevin Pauli

Answer 6

存储过程

• 优点：封装数据访问代码，不依赖于应用程序。
• 缺点：可能与关系型数据库系统相关，会增加开发时间。

ORM（对象关系映射）

至少有一些ORM允许映射到存储过程

• 优点：抽象了数据访问代码，允许以领域特定的方式编写实体对象。
• 缺点：可能存在性能开销和有限的映射能力。

代码生成

• 优点：可以用于生成基于存储过程的代码、ORM或两者混合的代码。
• 缺点：必须维护代码生成器层，并理解生成的代码。

- marxidad