古老的问题.您应该将业务逻辑放在数据库中作为存储过程(或包),还是应用程序/中间层？更重要的是,为什么？
假设数据库独立性不是目标.
在确定业务逻辑应该去哪里时,代码的可维护性始终是一个大问题.
集成的调试工具和功能更强大的IDE通常使维护中间层代码比存储过程中的相同代码更容易.除非有其他原因,否则您应该从中间层/应用程序中的业务逻辑开始,而不是在存储过程中.
但是,当您进行报告和数据挖掘/搜索时,存储过程通常可以更好地进行选择.这要归功于数据库聚合/过滤功能的强大功能以及您保持处理非常接近数据源的事实.但这可能不是大多数人认为的经典商业逻辑.
在数据库中放入足够的业务逻辑,以确保数据的一致性和正确性.
但是,不要害怕必须在另一个级别复制一些逻辑以增强用户体验.
对于非常简单的情况,您可以将业务逻辑放在存储过程中.通常即使是简单的情况也会随着时间的推移变得复杂.以下是我没有将业务逻辑放在数据库中的原因:
将业务逻辑紧密地放在数据库中会将其与数据库的技术实现紧密结合在一起.更改表将导致您再次更改大量存储过程,从而导致大量额外错误和额外测试.
通常,UI依赖于业务逻辑来进行验证.将这些东西放在数据库中将导致数据库和UI之间的紧密耦合,或者在不同情况下重复这两者之间的验证逻辑.
很难让多个应用程序在同一个数据库上运行.一个应用程序的更改将导致其他应用程序中断.这很快就会变成维护噩梦.所以它并没有真正扩展.
更实际的是,SQL不是一种以可理解的方式实现业务逻辑的好语言.SQL非常适合基于集合的操作,但它错过了"大规模编程"的构造,很难维护大量的存储过程.现代OO语言更适合并且更灵活.
这并不意味着您无法使用存储过程和视图.我认为在表和应用程序之间放置一层额外的存储过程和视图来解耦这两者是一个好主意.这样,您可以在不更改外部接口的情况下更改数据库的布局,从而允许您独立地重构数据库.
只要你保持一致,这完全取决于你.
将它放在数据库层中的一个很好的理由:如果您非常确定您的客户端永远不会更改其数据库后端.
将其放入应用程序层的一个很好的理由:如果您要为应用程序定位多个持久性技术.
您还应该考虑核心竞争力.您的开发人员主要是应用程序层开发人员,还是主要是DBA类型？
虽然在应用程序层上拥有业务逻辑肯定有好处,但我想指出语言/框架似乎比数据库更频繁地更改.
我支持的一些系统在过去10到15年中经历了以下UI:Oracle Forms/Visual Basic/Perl CGI/ASP/Java Servlet.没有改变的一件事 - 关系数据库和存储过程.
虽然没有一个正确的答案 - 这取决于有问题的项目,我会推荐Eric Evans 在" Domain Driven Desig n"中倡导的方法.在这种方法中,业务逻辑在其自己的层中被隔离 - 域层 - 位于基础架构层之上 - 可能包括您的数据库代码,并位于应用层之下,后者将请求发送到域层履行并听取确认完成,有效地推动申请.
通过这种方式,业务逻辑被捕获在一个模型中,可以与那些除了技术问题之外理解业务的人讨论,并且应该更容易隔离业务规则本身的变化,技术实现问题和流程.与业务(域)模型交互的应用程序.
如果你有机会,我建议阅读上面的书,因为它非常擅长解释这个纯粹的理想如何在真实的代码和项目的现实世界中实际近似.
任何影响数据完整性的事情都必须放在数据库级别.除了用户界面之外的其他事情通常是将数据放入,更新或删除数据库中的数据,包括导入,批量更新以更改定价方案,热修复等.如果您需要确保始终遵循规则,请将逻辑置于默认值和触发器.
这并不是说在用户界面中也没有它是一个好主意(为什么要发送数据库不会接受的信息),但忽略数据库中的这些东西是为了惹恼.
在这种情况下,提问者排除作为考虑因素的数据库独立性是将逻辑从数据库中取出的最强有力的论据.数据库独立性的最有力论据是能够将软件销售给具有数据库后端自身偏好的公司.
因此,我认为将存储过程从数据库中取出的主要论点仅仅是商业过程,而不是技术过程.可能存在技术原因,但也有技术原因可以将其保留在那里 - 性能,完整性以及允许多个应用程序使用相同API的能力.
是否使用SP也会受到您要使用的数据库的强烈影响.如果您不考虑数据库独立性,那么您将使用T-SQL或使用PL/SQL获得非常不同的体验.
如果您使用Oracle开发应用程序,那么PL/SQL作为一种语言显然是一种选择.它与数据紧密耦合,在每个版本中不断改进,任何体面的开发工具都会将PL/SQL开发与CVS或Subversion等集成在一起.
Oracle的基于Web的Application Express开发环境甚至可以使用PL/SQL 100%构建.
如果您需要数据库独立性,您可能希望将所有业务逻辑放在应用程序层中,因为应用程序层中的可用标准比数据库层可用的标准更为普遍.
但是,如果数据库独立性不是第一因素,并且团队的技能集包括强大的数据库技能,那么将业务逻辑放在数据库中可能是最佳解决方案.您可以让您的应用程序人员执行特定于应用程序的事情,并让您的数据库人员确保所有查询都可以运行.
当然,能够将SQL语句放在一起并拥有"强大的数据库技能"之间存在很大差异 - 如果您的团队比前者更接近前者,那么使用这个世界的一个Hibernates将逻辑放入应用程序中(或改变你的团队!).
根据我的经验,在企业环境中,您将拥有该领域的单一目标数据库和技能 - 在这种情况下,您可以将所有内容都放在数据库中.如果您从事软件销售业务,数据库许可证成本将使数据库独立性成为最大因素,您将在应用程序层中实现所有可能的功能.
希望有所帮助.
现在可以提交subversion存储的proc代码并使用良好的工具支持调试此代码.
如果使用组合sql语句的存储过程,则可以减少应用程序与数据库之间的数据流量,并减少数据库调用次数并获得较大的性能提升.
一旦我们开始使用C#构建,我们决定不使用存储过程,但现在我们正在将越来越多的代码移动到存储过程中.特别是批量处理.
但是,不要使用触发器,使用存储过程或更好的包.触发确实会降低可维护性.
京公网安备 11010802040832号 | 京ICP备19059560号-6 