标签：字符串 不同的 .com 架构 亚马逊 控制 问题 aik 分析
不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑 比如让你实现一个功能，给你两个数，让你获取它的和，你所写的如何才能获得任意给定的两个数的和，这个程序实现过程即可成为业务逻辑处理。
“一个人了解的业务逻辑越多越细，他就是越好的需求分析师。”
难题：什么是业务逻辑？
业务是指一个实体单元向另一个实体单元提供的服务。
逻辑是指根据已有的信息推出合理的结论的规律。
业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。
就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。
在软件系统架构中，软件一般分为三个层次：表示层、业务逻辑层和数据访问层：
业务逻辑的内容包括四个部分：
以大毛网购裤子为例
业务逻辑：搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。
当当必须登录账号才能下单成功，亚马逊就不需要，今天发现淘宝也不需要登录账号就能购买商品了，所以每个网站的规则的不同，就形成了不同的业务逻辑，业务逻辑不仅仅包括规则，还包括实体、数据完整性、工作流。如图：
业务逻辑图
业务逻辑也需要画图，叫做业务逻辑图，它跟业务流程图有什么区别呢？
业务流（工作流）是业务逻辑的一部分，它定义了对象之间的交互关系，但不涉及到规则的制定，数据的完整性方面。
其实，我们平常画的业务流程图多数是业务逻辑图。
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模式解耦。至于业务，看你怎么定义领域模型了，一般像上传文件这种操作并不会牵扯企业的业务，那就不应该当做一个业务，但如果这个上传是在工作流或者一些特殊处理中，则有可能上升到业务。怎么做，要看具体问题。
标签：字符串 不同的 .com 架构 亚马逊 控制 问题 aik 分析
原文地址：https://www.cnblogs.com/kaisadadi/p/9265196.html
