逻辑部分-开发原则

【目的】

原则性指导业务逻辑设计处理；具体项目（模块）具体分析。

 

原则：

一、逻辑涉及范围仅在完整的应用模块

二、逻辑的处理需要考虑存储上关系的紧密程度

三、业务逻辑处理的层次最好在3层以内，不能无限传递

 

常规下，一个项目包括多个应用模块，每一个应用模块都需要各自的存储资源，且有自身的一套处理流程

每一个应用模块都有对应的前置条件、后置条件。

 

那么模块的粒度不要过于小巧，也不要过于庞大

 

【具体演示】

现在常规项目开发都是采用N层结构（其中包括DB访问层（Sp）和业务逻辑层），DB存储

DB访问层：调用的是SP（存储过程），输出原始数据

业务逻辑层：调用的是DB访问层，输出已处理或前台需要的数据

 

场景一：

管理员保存公告

分析：角色（管理员），动作（保存），对象（公告）

业务上来说，公告模块属于独立的模块应用，完整的

发布公告的人和公告本身无关

 

那么：DB访问层下的SP可以完全公开，其公告的处理逻辑（权限）全由业务层处理

 

场景二：

评论流程，一张评论表，一张对象表（包括一个静态字段：评论数）。

那么，每次保存评论时，更新评论数应该由SP来完成还是业务处理层完成

 

个人建议：SP完成

原因：减小通讯和DB链接次数

 

场景三：

网购流程：下单->支付->更新支付状态->更新下单状态

此类逻辑处理采用一致方式处理，也就是说：SP必须限定，业务也要限定，切限定逻辑一致，但允许方式不一样

 

最后，也许此文描述的不恰当，望不断修正。

 

开发团队建议人员：

1、系统开发员

2、DB开发员

3、业务开发员

4、前台开发员

5、测试开发员

 

此文涉及人员是前3类，2和3协商处理逻辑｛协商问题：逻辑重点在DB还是业务，还是分别实现同一逻辑处理｝，实在不好确定的，由1来拍板实现逻辑

 

希望此文对自己以后开发有帮助和提升！

 

软件重点在于业务逻辑，切记！

 

转载于:https://www.cnblogs.com/GoGoagg/archive/2010/09/17/1829323.html