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

Question

这些软件体系结构在哪些领域发挥作用或失败？

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

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

另外，请避免神圣的战争:)这三种技术都有利有弊，我对哪种方式最适合使用感兴趣。

Answer 1

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

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

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

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

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

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

Answer 2

我要加两分钱：

存储过程

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

<强>的ORM

• 让您只关注领域，并采用更“纯粹”的面向对象的开发方法
• 当您的应用程序必须与数据库兼容时发光
• 当您的应用程序主要由行为而不是数据驱动时闪耀

代码生成器

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

Answer 3

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

请查看关于该主题的其他两篇帖子（动态SQL vs 存储过程与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?

Answer 4

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

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

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

Answer 5

存储过程

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

<强> ORM

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

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

代码生成

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

Answer 6

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

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