继续探讨三层关系

每天的理解都不相同，对于这些东西，骑车回家的路上，浮现在大脑里~~~

上一篇提到了DAO，Business，UI，提到了MVC，曾几何时，我们会认为，业务逻辑就是controller，bean（就是与数据库表对应的实体bean）当作了model，七七八八的开始搭配起来，因为见的东西少，基础知识薄弱，写的多了就开始出现一些误区，当然在实践中，会慢慢的改变这些错误的观点，因为见的多了，懂的多了。

开始接触的时候，不知道什么叫做数据访问，不知道什么是业务逻辑，什么是跳转控制，就是一个页面给到后台，一通处理之后，再传递给前台页面，当然这就是一次访问的过程，我个人觉得这也许就是MVC吧。这是不是也可以解释Struts是一个轻量级的MVC框架呢？

后来，接触的多了，处理多了，于是开始把它分层处理了，习惯把数据访问层提取出来，把主要的逻辑处理提取出来，抽取出一些数据模型，让原来的后台处理就留一些跳转，参数封装成数据模型的东西。大家有没有发现，我们做的是在服务器端的处理做了细化，其实我们一直在操作的还是C的内容，而这里的数据访问层就是DAO了，逻辑处理就是业务逻辑层，原来的那个东西就成为了表现层了。

那有人会想到，不是还有模型么，它属于什么呢？它就是DTO，数据传输对象，承载的是服务器与客户端之间交互的对象。这个时候，大家有没有想到我们曾经用的bean这个东西，是不是有点偏差了。那么与数据库对应的实体bean是什么呢？它就是持久化对象PO，它是怎么变化出来的呢。

当接收到一个请求的时候，我们需要得到一个数据传输对象，这个对象由多个业务对象加一些其他信息组合起来，所以我们调取业务逻辑层的对象，获取业务对象，业务对象是由多个持久化对象拼起来的，这个时候我们就用到了PO的对象，每一次对数据库的操作，都对应着关系与对象之间的相互转换，所以PO就是完成这样的任务了。综合看来，DTO分析处理，拆分到BO，BO分析拆分，得到多个PO，然后我们将PO按照业务逻辑与数据库交互的这么一个过程，而同一个业务逻辑下，常常又存属在一个事务中。按照栈的思路，DAO先做处理完毕后，返回到业务逻辑层，再形成DTO，到达表现层，回馈给请求用户。

以上是我今天想到的一点点小东西，积攒起来，希望大家多多指点~