层间的数据传递
马克-to-win：一 个数据库中的表对应一个PO（Persistant Object），这好理解。在Web层的网页，当用户提交表单数据以后，在Controller层，把表单数据放在VO（View Object有人也叫Value Object） 当中，接着调用Service层。VO相对于网页表单数据，也许对应n个PO，而且和PO数据格式也许不一样。马克-to-win：（表单2012/1/1而数据库中是 2012-1-1）。Service层原始接受的数据是VO，但在这里，Service层把它变成DTO（Data Transfer Object）。DTO不用于VO，不但因为二者功能不同，（DTO用于专门的层间传输，VO用于持有表单数据）而且DTO也许有很多VO里没有的数据， 比如Service层的方法现场产生的加密密码，各种加密的标志，收到的短信验证码等。马克-to-win：Service层接着调用BO，BO调用DO，（这个过程 应该是涉及的业务范围越来越小，越来越具体，就像中央委托给东北局，东北局再委托给辽宁省，处理某个事一样），DTO在这个过程中承载的数据量也必然越来 越小。马克-to-win：既然有可能Service层和BO层或DO层不在同一台电脑上，为了节约网络带宽并提高系统性能，我们可以推出若干BoDto和DoDto的概念， 使它仅封装BO和DO需要的数据，当然采用BoDto和DoDto系统，会有越来越多的各种DTO，所以我们实际中宁愿使用粗粒DTO(即包含比需要多的 属性)，而不是重新编写一堆新的各种各样的DTO，前提是只要冗余数据不是太多。马克-to-win：在代码量代码复杂度和系统性能之间做取舍是我们工程师永恒的话题。技术教 会大家，大家起码可以有做选择的机会。当DTO进入到DO层以后，经过DO的复杂处理后，当需要被传给Dao层，压入数据库之前一瞬间，就需要被变成PO 了。Dao层就相对简单了。
马克-to-win：注 意VO，PO，DTO都是没有业务方法的。只是数据而已。它们的存在使得层与层之间更好的解耦。（一层的改变不妨碍另一层）。分工越精细化，越不容易出 错。作为项目负责人的未来的你，要时刻谨记，今天这堆做项目的人，未来很有可能变成一波新人。马克-to-win：更有甚者，你们正在做一个外包项目。只有大家符 合一套严格的规矩，在更换人员，变换需求时，才能应付自如。
更多请看：https://blog.csdn.net/qq_44594371/article/details/103182408
