Language agnostic 代码生成器vs.ORMs vs.存储过程

这些软件体系结构中的每一个都在哪些领域发挥作用或失败

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

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

---

另外，请避免圣战：）这三种技术都有优点和缺点，我感兴趣的是哪种技术最适合使用。

我同意每种技术都有优点和缺点，这在很大程度上取决于您的体系结构。也就是说，我试图在有意义的地方使用ORM。很多功能已经存在，通常它们有助于防止SQL注入（另外，它还可以帮助避免重新发明轮子）

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

动态SQL与存储过程的比较

ORMs与存储过程的比较

---

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

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

---

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

存储过程

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

ORM

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

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

代码生成

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

---

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

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

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

• ORMs是集成工具的理想选择，在集成工具中，您可能需要在安装到安装的基础上处理不同的rdbmse和模式。更改一个映射后，您的应用程序将从在Oracle上与PeopleSoft协作转向在SQL Server上与Microsoft Dynamics协作

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

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

我再加上我的两分钱：

存储过程

• 可以很容易地进行优化
• 抽象基本业务规则，增强数据完整性
• 提供良好的安全模型（无需向面向前端的db用户授予读写权限）
• 当您有多个应用程序访问同一数据时，它将大放异彩

ORMs

• 让您只关注领域，并使用更“纯”的面向对象方法进行开发
• 当您的应用程序必须与跨数据库兼容时，请亮起
• 当您的应用程序主要由行为而不是数据驱动时，它将大放异彩

代码生成器

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

---

您忘记了一个值得拥有自己类别的重要选项：一个混合数据映射框架，如

---

我对iBatis很满意，因为它让您的OO代码保持OO的性质，数据库保持关系的性质，并通过添加第三个抽象（对象和关系之间的映射层）来解决阻抗不匹配问题，该抽象层负责映射两者，我知道这是一篇老生常谈的文章，但对于ORM来说，一个积极的方面是，他们通常不使用任何资源来管理缓存