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

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

哪些关键要求会促使您选择一个而不是另一个？

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

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

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

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

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

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

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

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

我加上我的两分钱:

存储过程

可以轻松优化

抽象的基本业务规则,增强数据完整性

提供良好的安全模型(无需向前端数据库用户授予读取或写入权限)

当您有许多应用程序访问相同的数据时闪耀

奥姆斯

让您只关注域,并采用更"纯粹"的面向对象的开发方法

当您的应用程序必须与数据库兼容时,请发光

当您的应用程序主要由行为而不是数据驱动时,请发光

代码生成器

为您提供与ORM类似的好处,具有更高的维护成本,但具有更好的可定制性.

通常优于ORM,因为ORM倾向于为运行时错误交换编译时错误,这通常是要避免的

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

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

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

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