对于初学者-正确理解业务逻辑

工作中，看到过一篇文章，特意做下笔记，摘抄下来，感谢原作者大大的分析： http://www.cnblogs.com/zhaoxiaolei/archive/2012/04/06/2434112.html

在开发中，经典的三层架构： 表示层，业务逻辑层，数据访问层，说到表示层和数据访问层我们有很清晰的认知，但业务逻辑层，往往就缄默了；

架构三层（MVC）

表示层：负责页面展示及用户交互

业务逻辑层： 数据访问交互处理，简而言之就是_数据在不同的层次进行传递过程中形成的各种关系_

数据访问层： 负责从数据库存储数据

###代码三层 action(controller)层： 一般用来验证数据非空，格式 ，及页面的跳转控制

service层: 一般是用来一个业务逻辑的实现，比如下订单： 验证订单》重复下单》下单后短信通知回馈用户

dao层： 读写数据库， 如生成一条订单记录；

###易错点

在MVC 很多的人在action中写业务代码，更有人把数据库的代码也写到了action中，这明明就不理解 分层的意思。应该做到各司其职。
1 . "对象间接的通过控制的aciton耦合一起" ： 典型的错误依赖，闭合依赖；

构架师制定框架，程序员去实现业务逻辑，是完美的结构。
DDD对于中小项目可能更有效率，但是对于大项目而言，可能会让架构师和程序员的工作分工不明确；
架构师过得考虑业务细节，而程序员则接触额外的是不属于其的自身的细节；徒劳增加开发成本和带来更多bug;

2 . 对象和aciton耦合在一起；
不利于项目的分模块，推荐方式： 制作中间模块，提高模块独立化；

3 .重要的事情都集中在控制器（或者dao层）中； 不过过分集中代码在某一块，使用spring可以更好地细化责任，更好地额执行开闭原则

总结： 打字真累，边打字边思想更累； 业务逻辑运用好的地方在于： 做socket编程，调用webService，业务对象持久化，失误控制，计划调度，消息等等均在业务逻辑层，根据功能，依赖关系进行分层，从维护的角度，可解耦； 分层的优势： 可维护，可扩展，可读性好；