关于不可知的语言：代码生成器与ORM与存储过程

Code generators vs. ORMs vs. Stored Procedures

这些软件体系结构在哪些领域大放异彩？

哪些关键要求会提示您选择一个？

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

另外，请避免进行圣战：)三种技术各有利弊，我对最适合使用哪种技术感兴趣。

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

如果您正在处理DBA"统治"的文化，那么基于存储过程的体系结构将更易于部署。另一方面，很难对存储过程进行管理和版本控制。
使用静态类型的语言时，代码生成器会发光，因为您可以在编译时而不是运行时捕获错误。
ORM是集成工具的理想选择，在集成工具中，您可能需要逐个安装地处理不同的RDBMS和架构。更改一张地图，您的应用程序就从在Oracle上与PeopleSoft一起使用转变为在SQL Server上与Microsoft Dynamics一起使用。

我已经看到了使用生成的代码与存储过程进行接口的应用程序，因为可以对存储过程进行调整，以解决代码生成器中的限制。

最终，唯一正确的答案取决于您要解决的问题和解决方案需要执行的环境。其他任何东西都在争辩" potato"的正确发音。

我加两分钱：

储存程序

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

ORM

让您仅专注于领域，并拥有更"纯"的面向对象的开发方法
当您的应用程序必须跨数据库兼容时发光
当应用程序主要由行为而非数据驱动时发光

代码生成器

为您提供与ORM相似的优势，不仅维护成本更高，而且可定制性更高。
通常优于ORM，因为ORM倾向于将编译时错误换为运行时错误，通常应避免这种情况

我同意所有内容都有优点和缺点，并且很大程度上取决于您的体系结构。话虽如此，我尝试在有意义的地方使用ORM。已经有很多功能，通常它们可以防止SQL注入(此外，它还有助于避免重新发明轮子)。

请参阅该主题的其他这两篇文章(动态SQL与
存储过程与ORM)以获取更多信息

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

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

ORM和代码生成器在某种程度上是领域，而存储过程则在另一侧。通常，在未开发项目中使用ORM和代码生成器会更容易，因为您可以定制数据库架构以匹配您创建的域模型。在遗留项目中使用它们要困难得多，因为一旦软件以"数据优先"的思维方式编写，就很难将其与域模型包装在一起。

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

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

您忘记了一个重要的选项，该选项应单独使用：混合数据映射框架，例如iBatis。

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

存储过程