15

这些软件架构各自在哪些领域发光或失败？

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

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

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

4

6 回答 6

13

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

  • 如果您正在处理一种 DBA “称雄”的文化，那么基于存储过程的体系结构将更易于部署。另一方面，管理和版本存储过程可能非常困难。

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

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

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

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

于 2008-09-16T20:42:10.363 回答
10

我会加两分钱：

存储过程

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

ORM

  • 让你只专注于领域，拥有更“纯”的面向对象的开发方式
  • 当您的应用程序必须与跨数据库兼容时闪耀
  • 当您的应用程序主要由行为而不是数据驱动时，您会大放异彩

代码生成器

  • 为您提供与 ORM 类似的好处，但维护成本更高，但可定制性更好。
  • 通常优于 ORM，因为 ORM 倾向于用编译时错误换取运行时错误，这通常是可以避免的
于 2008-09-16T20:44:42.773 回答
5

我同意每件事都有利有弊，很大程度上取决于您的架构。话虽如此，我尝试在有意义的地方使用 ORM。许多功能已经存在，通常它们有助于防止 SQL 注入（另外它有助于避免重新发明轮子）。

有关更多信息，请参阅有关该主题的其他两篇文章（动态 SQL 与存储过程与 ORM）

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

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

于 2008-09-16T20:14:39.557 回答
3

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

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

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

于 2008-09-16T20:24:38.097 回答
2

存储过程

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

甲骨文

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

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

代码生成

  • 优点：可用于生成基于存储过程的代码或 ORM 或两者的混合
  • 缺点：除了理解生成的代码之外，可能还必须维护代码生成器层
于 2008-09-16T20:30:06.477 回答
2

您忘记了一个值得拥有自己类别的重要选项：混合数据映射框架，例如iBatis。

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

于 2008-09-19T20:38:53.720 回答