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

Question

这些软件体系结构中的每一个在哪些域中发光或失败？

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

请假设您有开发人员可以完成面向对象的代码以及良好的数据库开发。另外，请避免神圣战争:)所有这三种技术都有优点和缺点，我感兴趣的是哪里最适合使用哪个。

Answer 1

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

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

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

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

我见过其中生成的代码使用存储过程进行接口的应用，因为存储过程可以被调整，以避开在代码生成器的限制。

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

Answer 2

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

请参阅有关的话题这另外两个职位（动态SQL VS 存储过程VS ORM）了解更多信息

动态SQL与存储过程
Which is better: Ad hoc queries, or stored procedures?

奥姆斯与存储程序
Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 3

ORM和c颂扬发生器在这个领域的一边，存储过程在另一边。通常，在绿地项目中使用ORM和代码生成器会更容易，因为您可以调整数据库架构以匹配您创建的域模型。将它们与传统项目一起使用要困难得多，因为一旦用“数据优先”的思维方式编写软件，就很难用域模型来包装它。

这就是说，所有这三种方法都有价值。存储过程可以更容易优化，但将应用程序本身可能重复的业务逻辑放入其中可能会很诱人。如果您的模式与ORM的概念相匹配，则ORM可以很好地工作，但如果不符合，可能很难定制。代码生成器可以是一个很好的中间立场，因为它们提供了ORM的一些好处，但可以自定义生成的代码 - 但是，如果您习惯于更改生成的代码，则会出现两个问题，因为您每次重新生成时都必须更改它。

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

Answer 4

存储过程

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

ORM

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

• 优点：文摘数据访问代码，并且允许实体对象域特定的方式
• 缺点将被写入：可能的性能开销和有限的映射能力

代码生成

• 优点：可用于基于存储的进程内码或ORM或两者
• 缺点的混合：代码生成层可能必须被保持在除了理解生成的代码

Answer 5

我将添加我的两分钱：

存储过程

• 可以很容易地优化
• 摘要基本业务规则，提高数据的完整性
• 提供良好的安全模型（无需授予读取或写入权限的前面临db用户）
• 闪耀，当你有很多应用程序NS访问相同的数据

奥姆斯

• 让你只集中在域拥有更“纯粹”的面向对象的方法来发展
• 服务，当您的应用程序必须是跨数据库兼容
• 当您的应用程序主要由行为而不是数据驱动时发光

代码生成

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

Answer 6

你忘了自己专门的类别显著选项：混合数据映射框架，如iBatis。

我对iBatis感到满意，因为它让您的OO代码在本质上保持OO，并且您的数据库本质上保持关系，并通过添加第三个抽象（对象与关系之间的映射层）来解决阻抗不匹配问题，这是负责绘制这两者的映射，而不是试图强迫适合另一种范式。