Gar*_*ero 5 java oracle business-logic application-layer
在阅读这篇文章(业务逻辑数据库或应用程序层)之后,我仍然没有足够的理由来对抗"数据库中的业务逻辑"主题.
在我目前的工作中,有很多db事务(实际上)和所有那些糟糕的代码很难维护,存储过程中有很多重复,所以如果你想在表中稍微改一个值,你会需要找到所有这些程序并将其更改为您想要的程序.如果你需要改变一点桌面设计,也会发生同样的情况.
所有当前的开发人员都非常了解SQL,但他们仍然不是任何DATABASE的专家作为引擎(8个开发者).
目前,我们计划将整个核心迁移到新版本(包括数据库设计).我需要一些例子:
应用程序语言:Java
数据库:Oracle11g
该应用程序将具有服务,作为HTTP页面和Web服务.
蹩脚的代码确实很难维护。这就是蹩脚代码的本质——而不是它所在的位置。转向“前端的蹩脚代码”解决方案实际上并不是一个解决方案。
如果您认为数据库结构更改不会影响前端编码的业务逻辑...嗯 - 逻辑规定不同。
我觉得有些事情在前端处理得好，有些事情在后端处理得更好。我认为，在业务对象级别运行的正确 PL/SQL API 设计可以通过将结构变更问题与其他层隔离来缓解结构变更问题。
但是，如果有任何支持其他数据库的想法，那么这也是一个有问题的想法，因为并非每个数据库都支持相同的结构。
至于业务逻辑属于哪里——这可能完全取决于您的应用程序，实际上，出于性能原因，您可能会发现将其某些方面放在多个层中是有利的。当然，这可能会导致维护问题，但这一切都成为交付项目或产品所需权衡的一部分。
但肯定不存在一个严格的通用答案。