n-tier(层)架构

 一，不断要去改。二来还得快。就必须要用n-tier（层）模式开发。这样我就可以把分工分得很细。需要改动时，可以一步到位，找到需要改动的地 方，而且还可以非常快。

n-tier架构，把model细化分成了几层。现在继续把其中的服务层（service）细化，变成 service层调用BO（Business Object）层，BO层调用DO（domain object）层。

1、DO（domain object）

DO是domain object，又叫领域对象。就是数据库中每个有现实意义的表都对应一个DO。比如多对多关系表在现实就没有意义 （TeacherStudentRelation），DO有自己的业务方法。

2、BO （Business Object）

BO就是现实中个别一个复杂对象或一堆有密切关系的DO对象所代表的抽象无形的有现实意义的概念对象。比如“手”和“ 脚”数据库中有实体表，所以“手”和“脚”都是DO。而“四肢 ”只是概念，没有表对应，是BO。

BO也有业务方法。service当中可能有些发Email的方法，或安全编码的方法，这些不涉及数据库，和BO不同 （BO涉及数据库）。当涉及到“手脚并用”时，就调用“四肢”这个BO当中的方法。这个方法当中涉及到“脚”的方法时，就调用“脚”这个DO的方法。 “脚”这个DO里的业务方法涉及到数据库时，就调用Dao中的方法。
 

一点简单的知识。1）delegate层即代理层，在Service层前面，很有可能和Controller层在不同的机器上和Tomcat上，等待着不同的Conrtroller的访问。小项目没有，比如你的项目可能有asp或c#访问，这样你的Model就真正成了跨平台的Model了。delegate再调用service层。2）Controller层：控制层，也叫domain主控制层。 负责jsp表单提交的处理，调用Service层或delegate层，将 Service层的数据对象返回到视图层。3）web层主要是客户端网页,就是所谓的View。 
 

 3、PO（Persistant Object）

一 个数据库中的表对应一个PO（Persistant Object），这好理解。在Web层的网页，当用户提交表单数据以后，在Controller层，把表单数据放在VO（View Object有人也叫Value Object） 当中，接着调用Service层。

4、VO（View Object 或 Value Object）

VO相对于网页表单数据，也许对应n个PO，而且和PO数据格式也许不一样。（表单2012/1/1而数据库中是 2012-1-1）。Service层原始接受的数据是VO，但在这里，Service层把它变成DTO（Data Transfer Object）。

5、DTO（Data Transfer Object）

DTO不用于VO，不但因为二者功能不同，（DTO用于专门的层间传输，VO用于持有表单数据）而且DTO也许有很多VO里没有的数据， 比如Service层的方法现场产生的加密密码，各种加密的标志，收到的短信验证码等。

Service层接着调用BO，BO调用DO，（这个过程 应该是涉及的业务范围越来越小，越来越具体，就像中央委托给东北局，东北局再委托给辽宁省，处理某个事一样），DTO在这个过程中承载的数据量也必然越来 越小。

 6、BoDto、DoDto

既然有可能Service层和BO层或DO层不在同一台电脑上，为了节约网络带宽并提高系统性能，我们可以推出若干BoDto和DoDto的概念， 使它仅封装BO和DO需要的数据，当然采用BoDto和DoDto系统，会有越来越多的各种DTO，所以我们实际中宁愿使用粗粒DTO(即包含比需要多的 属性)，而不是重新编写一堆新的各种各样的DTO，前提是只要冗余数据不是太多。

当DTO进入到DO层以后，经过DO的复杂处理后，当需要被传给Dao层，压入数据库之前一瞬间，就需要被变成PO 了。Dao层就相对简单了。

注意：VO，PO，DTO都是没有业务方法的。只是数据而已。它们的存在使得层与层之间更好的解耦。（一层的改变不妨碍另一层）。分工越精细化，越不容易出 错。作为项目负责人的未来的你，要时刻谨记，今天这堆做项目的人，未来很有可能变成一波新人。