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

Posted 2023-03-28

技术标签:

【中文标题】代码生成器与 ORM 与存储过程【英文标题】：Code generators vs. ORMs vs. Stored Procedures 【发布时间】：2010-09-09 17:40:22 【问题描述】：

这些软件架构在哪些领域大放异彩？

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

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

另外，请避免圣战 :) 这三种技术各有利弊，我感兴趣的是最适合使用哪种技术。

【问题讨论】：

【参考方案1】：

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

如果您正在处理一种 DBA '称雄'的文化，那么基于存储过程的体系结构将更易于部署。另一方面，管理和版本存储过程可能非常困难。

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

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

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

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

【讨论】：

我知道这是一篇旧文章，但对于 ORM 来说，一个积极的方面是它们通常开箱即用地管理缓存，如果你想像它一样处理存储过程，这是一个 PITA手动完成。【参考方案2】：

我会加两分钱：

存储过程

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

ORM

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

代码生成器

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

【讨论】：

【参考方案3】：

我同意每件事都有利有弊，而且很大程度上取决于您的架构。话虽如此，我尝试在有意义的地方使用 ORM。许多功能已经存在，通常它们有助于防止 SQL 注入（另外它有助于避免重新发明***）。

请参阅有关该主题的另外两篇文章（动态 SQL 与存储过程与 ORM）了解更多信息

动态 SQL 与存储过程Which is better: Ad hoc queries, or stored procedures?

ORM 与存储过程Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

【讨论】：

【参考方案4】：

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

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

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

【讨论】：

【参考方案5】：

存储过程

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

ORM

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

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

代码生成

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

【讨论】：

【参考方案6】：