码迷,mamicode.com
首页 > 其他好文 > 详细

把业务逻辑写在存储过程中有哪些缺点和优点?

时间:2019-11-02 11:52:22      阅读:160      评论:0      收藏:0      [点我收藏+]

标签:拖拉   net   修改   实现   blank   建模   技术   优点   需要   

https://segmentfault.com/q/1010000000251484

我的观点:这么设计的目的并不能方便随时修改业务逻辑,只是方便熟悉存储过程的开发人员,能够随时修改业务逻辑。对于后续的业务逻辑越趋于复杂,修改就越困难,存储过程中的重复代码就越多;重复代码越多,系统的坏味道就越散发开来。

由于.net在一些系统UI展示控件上,跟数据库集成,非常方便用户开发,简单的拖拖拉拉,再链接数据库,就能搞出一些像样的东西出来。这对系统逻辑不是很复杂的情况下,开发简单高效,且由于逻辑不是很复杂,也容易维护,所以很有优势。

但是系统的逻辑一旦达到一定的复杂度,把业务逻辑都放在存储过程中就会有2个很大的弊端,一是把系统的压力全都压到数据库上,这样势必增加系统的风险,且针对将来的负载增加的时候,不容易做水平扩展;二是业务逻辑放到存储过程,维护比较困难,且对于一些业务扩展,势必会增加冗余的代码,这样也会增加系统出bug的风险。

所以,在考量一个设计方案的时候,要综合系统的复杂度、技术实现平台等各方面。例如,对于技术实现平台,.net提供了这种集成数据库的UI控件,能够有效实现数据驱动,开发简单高效,但java就无法提供这种优势(ps:一般把这种叫做【表模块】设计方式);对于系统复杂度很高,为了应付后续的需求,一般会考虑【领域模型】设计方式,通过对业务进行领域建模,利用面向对象的各种设计模式,能够有效满足业务需求,且将系统压力分流到应用端,通过应用端的水平扩展,更方便系统扩容。

由于不了解你们系统的业务复杂程度,所以也不能说现有的基于存储过程的设计方式有什么问题,这需要你根据你们系统的需求等各方面综合来评估。最后推荐一本书:企业应用架构模式

 

把业务逻辑写在存储过程中有哪些缺点和优点?

标签:拖拉   net   修改   实现   blank   建模   技术   优点   需要   

原文地址:https://www.cnblogs.com/chucklu/p/11780774.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!