存储过程中的所有业务逻辑

Question

我的项目使用 N 层架构和通用框架：

• 表示层：JSF 2.0 + Primefaces
• 业务逻辑层：用于管理事务的 Spring
• 数据访问层：Spring Data + JPA
• 用于安全和用户管理的 Spring security
• 用于与外部系统集成的 Spring 集成

对于几乎所有的业务逻辑，我们都使用 Java 代码并驻留在业务层中，但我的客户要求我们将所有业务逻辑移入数据库并使用存储过程（数据库是 Oracle）。

如果将业务逻辑移至数据库，如下所示，我试图说服我的客户并给出一些劣势和优势：

缺点：

• 存储过程不是编程语言，它应该用于管理数据而不是编写逻辑代码
• 存储过程使逻辑变得复杂。使用存储过程可能难以实现一种逻辑，但如果使用 Java 等编程语言则非常容易
• 难以调试或单元测试
• 难以处理异常
• 难以维护、更新
• 存储过程无法与外部系统集成
• 当 ORM 框架对 CRUD 非常有用时，请花很多精力为每个表编写 CRUD
• 设计文档难以清晰
• 更多错误
• 减缓开发过程
• 数据库服务器将过载
• 数据库应该用于处理数据而不是用于流程逻辑
• 升级或添加新的数据库服务器既困难又昂贵，但使用应用服务器更容易且更便宜
• 打破 N 层架构和 ORM 框架

使用存储过程时：

• 性能：使用数据库处理批处理数据或长时间处理（作为报告...）

我的客户还说：他们想使用商店来修复项目而不重新部署。我解释说，当改变业务逻辑时，可能我们需要改变输入、输出和用户界面，那么我们仍然需要重新部署，我们应该把业务逻辑从数据库中拿出来。但他们拒绝了。

Answer 1

如果您使用 ORACLE DB，那么永远不要试图低估存储过程的力量。我曾在许多非常繁重的应用程序中工作，是的，它们有 JAVA 层，但是在 JAVA 层根本不可能使用业务逻辑处理大量数据。所以我们将大部分数据处理逻辑移到了存储过程中，它就像任何东西一样摇摆不定。

举个例子，你想在前端显示一个逻辑报告，你确定它只有几个 Kbs，你知道生成这个报告你调用 DB 并以 MB 为单位获取记录并在 JAVA 中执行业务逻辑，是吗？快点？？

我是 java 人，但仍然支持存储过程，因为即使你可以在其中编写有用的业务逻辑，你也可以做很多事情。

存储过程也适用于 DB 层，因此它总是比 JAVA 快。根据我的观点，您在 JAVA 业务层中的复杂 DB 相关查询只需移动到存储过程并使用 java 检索所需的输出并显示前端也一样。

此外，我想把存储过程的最佳优点。

• 它更快，因为多个 SQL 查询等可以在一次“往返”数据库中执行

• 使用来自多个应用程序的存储过程很简单

• 一个地方比多个地方更容易维护

• 数据库快速且经过优化，可以很好地扩展。

• 可以从多种不同的框架和语言调用相同的过程。

• 逻辑与特定应用程序中的实现分离。

• 当数据库保持不变时，可以减少更改应用程序的返工。