java - DataLayer的业务逻辑、应用层放在哪里？

Question

看完这篇文章后(business logic database or application layer ) 我仍然没有足够的理由来反对“数据​​库中的业务逻辑”这个话题。

在我目前的工作中，有很多数据库事务(实际上)，所有那些蹩脚的代码都很难维护，存储过程中有很多重复，所以如果你想稍微改变一下表中的值，您将需要找到所有这些程序并将它们更改为您想要的。如果您需要稍微更改表格设计，也会发生同样的情况。

所有当前的开发人员都非常了解 SQL，但他们仍然不是任何数据库作为引擎的专家(8 位开发人员)。

目前我们正计划将整个核心迁移到新版本(包括数据库设计)。我需要一些例子:

• 为什么数据库中的业务逻辑有时是邪恶的？
• 数据库中的业务逻辑在多大程度上以及何时是一个好的实践？
• 为什么应用层中的业务逻辑更适合企业应用程序。 ?

应用语言:Java
数据库:Oracle11g
该应用程序将具有服务，作为 HTTP 页面和 Web 服务。

Answer 1

糟糕的代码确实很难维护。这就是蹩脚代码的本质——而不是它所在的位置。转移到“前端糟糕的代码”解决方案并不是真正的解决方案。

如果您认为数据库结构变化不会影响前端编码的业务逻辑...嗯 - 逻辑要求不同。

我觉得有些东西前端处理的好，有些东西后端处理的好。而且我认为在业务对象级别运行的适当 PL/SQL API 设计可以通过将结构更改问题与其他层隔离来减轻结构更改问题。

但如果有任何支持其他数据库的想法，那么这也是一个有问题的想法，因为并非每个数据库都支持相同的结构。

至于业务逻辑属于何处 - 这可能完全取决于您的应用程序，实际上，出于性能原因，您可能会发现将它的某些方面放在多层中是有利的。当然，这可能会导致维护问题，但这一切都成为交付项目或产品所必需的权衡的一部分。

但肯定没有一个严格的通用答案。