代码生成器对比ORM 对比存储过程

Question

这些软件架构在哪些领域表现出色或失败？

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

请假设您有可用的开发人员，他们可以完成良好的面向对象代码以及良好的数据库开发。

另外，请避免圣战:)所有三种技术都有优点和缺点，我感兴趣的是在哪里最适合使用哪种技术。

Answer 1

这些工具中的每一个都提供不同的抽象层，以及覆盖行为的不同点。这些是架构选择，所有架构选择都取决于技术、控制和组织之间的权衡，包括应用程序本身和部署环境。

• 如果您面对的是 DBA 称霸的文化，那么基于存储过程的架构将更容易部署。另一方面，存储过程的管理和版本控制可能非常困难。

• 当您使用静态类型语言时，代码生成器会大放异彩，因为您可以在编译时而不是运行时捕获错误。

• ORM 是集成工具的理想选择，您可能需要在安装到安装的基础上处理不同的 RDBMS 和模式。更改一张地图，您的应用程序就会从使用 Oracle 上的 PeopleSoft 变为使用 SQL Server 上的 Microsoft Dynamics。

我见过使用生成代码与存储过程进行交互的应用程序，因为可以调整存储过程以绕过代码生成器中的限制。

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

Answer 2

我会添加我的两分钱：

存储过程

• 可以轻松优化
• 抽象基本业务规则，增强数据完整性
• 提供良好的安全模型（无需向前端数据库用户授予读或写权限）
• 当您有许多应用程序访问相同数据时，就会大放异彩

ORM

• 让你只专注于领域，拥有更“纯粹”的面向对象的开发方式
• 当您的应用程序必须跨数据库兼容时大放异彩
• 当您的应用程序主要由行为而不是数据驱动时，就会大放异彩

代码生成器

• 为您提供与 ORM 类似的好处，但维护成本更高，但可定制性更好。
• 通常优于 ORM，因为 ORM 倾向于将编译时错误换成运行时错误，而这通常是要避免的

Answer 3

我同意一切都有利有弊，很大程度上取决于您的架构。话虽这么说，我尝试在有意义的地方使用 ORM。许多功能已经存在，通常它们有助于防止 SQL 注入（此外，它还有助于避免重新发明轮子）。

有关更多信息

动态 SQL 对比存储过程
哪个更好：即席查询或存储过程？

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

Answer 4

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

话虽这么说，这三种方法都有价值。存储过程更容易优化，但很容易将可能在应用程序本身中重复的业务逻辑放入其中。如果您的模式与 ORM 的概念相匹配，则 ORM 可以很好地工作，但如果不匹配，则可能很难自定义。代码生成器可以是一个很好的中间立场，因为它们提供了 ORM 的一些好处，但允许自定义生成的代码——但是，如果您养成了更改生成的代码的习惯，那么您就会遇到两个问题，因为您每次重新生成它时都必须更改它。

没有一个真正的答案，但我更倾向于 ORM 方面，因为我相信以对象优先的心态思考更有意义。

Answer 5

存储过程

• 优点： 封装数据访问代码并且独立于应用程序
• 缺点： 可以是 RDBMS 特定的并增加开发时间

ORM

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

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

代码生成

• 优点： 可用于生成基于存储过程的代码或 ORM 或两者的混合
• 缺点： 除了理解生成的代码之外，还可能需要维护代码生成器层

Answer 6

您忘记了一个值得单独分类的重要选项：混合数据映射框架，例如 巴蒂斯.

我对 iBatis 很满意，因为它让您的 OO 代码本质上保持 OO，并且您的数据库本质上保持关系，并通过添加第三个抽象（对象和关系之间的映射层）来解决阻抗不匹配问题，该抽象负责映射两者，而不是试图强迫一种范式适应另一种范式。