业务逻辑详解拓展（转载）

　　不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑
　　比如让你实现一个功能，给你两个数，让你获取它的和，你所写的如何才能获得任意给定的两个数的和，这个程序实现过程即可成为业务逻辑处理。

　　“一个人了解的业务逻辑越多越细，他就是越好的需求分析师。”

　　难题：什么是业务逻辑？

　　业务是指一个实体单元向另一个实体单元提供的服务。
　　逻辑是指根据已有的信息推出合理的结论的规律。

　　业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。

　　就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。

　　在软件系统架构中，软件一般分为三个层次：表示层、业务逻辑层和数据访问层：

　　表示层：负责界面和交互；
　　业务逻辑层：负责定义业务逻辑（规则、工作流、数据完整性等），接收来自表示层的数据请求，逻辑判断后，向数据访问层提交请求，并传递数据访问结果，业务逻辑层实际上是一个中间件，起着承上启下的重要作用；
　　数据访问层：负责数据读取。

　　业务逻辑的内容包括四个部分：

　　领域实体：定义了业务中的对象，对象有属性和行为；
　　业务规则：定义了需要完成一个动作，必须满足的条件；
　　数据完整性：某些数据不可少；
　　工作流：定义了领域实体之间的交互关系。

以大毛网购裤子为例

领域实体：大毛、资金账户、订单、裤子、发货单
业务规则：大毛点击购买就会生成订单，但必须付了钱，才会发货，生成发货单。
数据完整性：淘宝网下订单必须登录账号，没有账号就不能成功购买。
工作流：搜索裤子-找到合意裤子-下单购买-付账-收货。
业务逻辑：搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。

当当必须登录账号才能下单成功，亚马逊就不需要，今天发现淘宝也不需要登录账号就能购买商品了，所以每个网站的规则的不同，就形成了不同的业务逻辑，业务逻辑不仅仅包括规则，还包括实体、数据完整性、工作流。如图：

 

业务逻辑图

业务逻辑也需要画图，叫做业务逻辑图，它跟业务流程图有什么区别呢？
业务流（工作流）是业务逻辑的一部分，它定义了对象之间的交互关系，但不涉及到规则的制定，数据的完整性方面。
其实，我们平常画的业务流程图多数是业务逻辑图。

所谓的三层开发就是将系统的整个业务应用划分为表示层，业务逻辑层和数据访问层，这样有利于系统的开发、维护、部署和扩展

。

　　分层是为了实现“高内聚，低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，延展
和分配资源。

　　所谓的三层开发就是将系统的整个业务应用划分为表示层，业务逻辑层和数据访问层，这样有利于系统的开发、维护、部署和扩展。
分层是为了实现“高内聚，低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，延展和分配资源。
业务逻辑层负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。对所输入的逻辑性数据的正确性及有效性负责，但对输出的逻辑性数 据及用户性数据的正确性不负责，对数据的呈现样式不负责。

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

 

原文链接：https://blog.csdn.net/u010098331/java/article/details/51700777