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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

我加上我的两分钱：

存储过程

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

奥姆斯

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

代码生成器

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

Answer 3

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

有关更多信息，请参阅有关该主题的其他两篇帖子（动态SQL与存储过程与ORM）

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

存储过程

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

ORM

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

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

代码生成

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