(转)业务逻辑详解

本文转自 csdn博客 白及 博主,原帖链接:https://blog.csdn.net/u010098331/article/details/51700777

不同的项目有不同的功能,不同的功能需要不同的实现,实现这些核心功能的代码就叫业务逻辑 比如让你实现一个功能,给你两个数,让你获取它的和,你所写的如何才能获得任意给定的两个数的和,这个程序实现过程即可成为业务逻辑处理。
一个人了解的业务逻辑越多越细,他就是越好的需求分析师。
难题:什么是业务逻辑?
业务是指一个实体单元向另一个实体单元提供的服务。
逻辑是指根据已有的信息推出合理的结论的规律。
业务逻辑是指一个实体单元为了向另一个实体单元提供服务,应该具备的规则与流程。
就像你家的规矩:“吃饭前必须洗手” “有客人来要起立” “睡觉前各自说晚安”。就是业务逻辑的生活化实例。在软件系统架构中,软件一般分为三个层次:表示层、业务逻辑层和数据访问层:
表示层:负责界面和交互;
业务逻辑层:负责定义业务逻辑(规则、工作流、数据完整性等),接收来自表示层的数据请求,逻辑判断后,向数据访问层提交请求,并传递数据访问结果,业务逻辑层实际上是一个中间件,起着承上启下的重要作用;
数据访问层:负责数据读取。
业务逻辑的内容包括四个部分:
领域实体:定义了业务中的对象,对象有属性和行为;
业务规则:定义了需要完成一个动作,必须满足的条件;
数据完整性:某些数据不可少;
工作流:定义了领域实体之间的交互关系。
以大毛网购裤子为例
领域实体:大毛、资金账户、订单、裤子、发货单
业务规则:大毛点击购买就会生成订单,但必须付了钱,才会发货,生成发货单。
数据完整性:淘宝网下订单必须登录账号,没有账号就不能成功购买。
工作流:搜索裤子-找到合意裤子-下单购买-付账-收货。
业务逻辑:搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。
当当必须登录账号才能下单成功,亚马逊就不需要,今天发现淘宝也不需要登录账号就能购买商品了,所以每个网站的规则的不同,就形成了不同的业务逻辑,业务逻辑不仅仅包括规则,还包括实体、数据完整性、工作流。如图:

 

业务逻辑图
业务逻辑也需要画图,叫做业务逻辑图,它跟业务流程图有什么区别呢?
业务流(工作流)是业务逻辑的一部分,它定义了对象之间的交互关系,但不涉及到规则的制定,数据的完整性方面。
其实,我们平常画的业务流程图多数是业务逻辑图。
分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展
和分配资源。
所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展。
分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展和分配资源。
业务逻辑层负责系统领域业务的处理,负责逻辑性数据的生成、处理及转换。对所输入的逻辑性数据的正确性及有效性负责,但对输出的逻辑性数 据及用户性数据的正确性不负责,对数据的呈现样式不负责。
JavaEE三层架构MVC,把视图控制器模型分开来
那么在这里业务逻辑就是M。
但是什么样的算是业务逻辑如:上传一个文件,上传代码算是一个业务逻辑吗?
数据库操作增加时需要判断,和一些其它这算业务逻辑吗?(我觉得算)
但是hibernate又提供了一个离线查询对象(DetachedCriter),提供这个接口的意思我想是在外面处理业务逻辑。
但是三层架构不是独立的吗?互相不干涉吗?在service层出现sql,hql,criter不是又把dao与service连在一起了吗?
DTO(VO),POJO,BO这些是什么,POJO对应数据库,BO对应业务逻辑,DTO对应页面的传输与显示。
业务逻辑就是处理数据的逻辑。一般后台代码也分三层 action(controller) service DAO (这里的三层不是MVC)
比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串,action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证,如用户名是否为空 是不是安全字符串之类的
service层一般是用来做一个业务逻辑的实现
这时候 userName = userName + new Date();
DAO层 就是与数据库交互层啦
  也就是读写数据库 将逻辑层得到的新的userName插入到数据库

MVC和三层架构并没有可比性三层架构是指将程序分为数据访问、业务处理、界面三个层次,是软甲整体架构MVC是仅仅是界面架构,也就是它其实只是三层架构的界面部分。

M是指实体模型或者实体模型的一个代理,而非领域模型,C是指控制器,仅仅是做转向,不应该包含任何业务逻辑,V就是视图。至于那些个什么什么O,都是实体在不同层的映射。另外值得一提的是,MVC在一些小的程序中也经常被当做软件整体架构,那个时候M往往就是实体模型了,但是这种时候,V就对M产生了直接引用,也就是界面对实体产生依赖,这是很不好的(但小程序问题不大),此时可以尝试使用MVP模式解耦。

至于业务,看你怎么定义领域模型了,一般像上传文件这种操作并不会牵扯企业的业务,那就不应该当做一个业务,但如果这个上传是在工作流或者一些特殊处理中,则有可能上升到业务。怎么做,要看具体问题。

   还没有人评论 到此为止 | 继续阅读 >>

发表评论

电子邮件地址不会被公开。 必填项已用*标注