代码生成器vs.ORM vs.存储过程

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

• 如果你正在处理一种DBA“主宰一切”的文化,那么基于存储过程的架构将更容易部署。另一方面,管理和版本存储过程可能非常困难。

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

• ORM是集成工具的理想选择,您可能需要在安装到安装的基础上处理不同的RDBMS和模式。更改一个映射,您的应用程序将从在Oracle上与PeopleSoft一起工作转变为在SQL Server上与Microsoft Dynamics一起工作。

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

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

我会加上我的两分钱:

存储过程

• 易于优化
• 抽象基本业务规则,增强数据完整性
• 提供良好的安全模型(无需向前置数据库用户授予读写权限)
• 当您有许多应用程序访问相同的数据时,它会闪闪发光

形式

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

代码生成器

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

我同意凡事都有利弊,很大程度上取决于你的架构。话虽如此,我试图在有意义的地方使用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?

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

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

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

存储过程

• 赞成的意见: 封装数据访问代码,独立于应用程序
• 欺骗: 可以是RDBMS特定的,并增加开发时间

形式

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

• 赞成的意见: 抽象数据访问代码,并允许以特定于域的方式编写实体对象
• 欺骗: 可能的性能开销和有限的映射能力

代码生成

• 赞成的意见: 可用于生成基于存储过程的代码或ORM,或两者的组合
• 欺骗: 除了理解生成的代码外,可能还必须维护代码生成器层

您忘记了一个值得单独分类的重要选项:混合数据映射框架,例如 iBatis .

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