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

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

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

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

解决方案

回答

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

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

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

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

回答

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

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

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

回答

存储过程

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

ORM

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

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

代码生成

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

回答

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

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

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

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

回答

我加两分钱：

储存程序

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

ORM

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

代码生成器

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

回答

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

我对iBatis感到很满意，因为它让OO代码本质上保持OO，数据库本质上保持关系，并通过添加负责映射两者，而不是试图使一种范例适合另一种范例。