VO(DTO)模式在分层架构设计中是否需要的扯淡

VO DTO POJO，都只是数据的封装而已，
如果每层交互都要做对象转换，重复代码多，
除了增加研发和维护的人力成本，意义究竟有多大，值得思考！

 

如果你看完本文，还不明白为什么要用。我就没有办法了。

就问楼主一个问题：OO中的Object与layer之间有啥关系，这个啥关系都没有的道理如搞不清楚，扯那些po，dto，vo都是浮云，浮动在层上的云。

死读书不如无书，具体问题灵活，灵活对待，
层与层之间的交互，不可能完全断开，就算是层与层之间数据对象转换，也算是一种耦合，
一旦上层数据结构有变动，很有可能会影响到下一层，
如：view层与service层传封装数据的vo或dto增减属性，很有可能会影响到service与dao层封装数据的po，
此时，将vo(dto)、po区分得太清楚，从设计角度看，貌似变清晰了，
而站在研发实际效果来看，是失败的。

站在交互的全流程的角度来看，view<-->service<-->dao，层与层之间的交互的“xo”，只是对数据的封装罢了，
采用统一的对象来处理，从实用主义来说，是合理的，这种应该是大多数情况，
一些特定场景，如“防火墙”、层与层之间，敏感数据隔离等，做有必要的转换，则是有意义的。

Rod Johnson在 J2EE without ejb中是反对用DTO的，他这么反对，相信是有他的道理的。

+1

关于Rod大叔反对，前面楼上有人说我们是断章取义了。哈哈。你可以了解一下。

从本质上讲，一般的系统，需要的只是从数据库到界面的一种映射，所以，原始的简单系统是jsp+sql来处理。

但是sql还是比较复杂的，加入了po作为数据库的代理，让这种复杂度的范围尽量缩小

而po和界面间的转换，并没有这种复杂度，加入vo很可能不能减少复杂度，反而增加复杂度。我觉得po和界面间，只需要定义好映射规则，就可以足够清晰了。

是这样的。我们大多数项目，都是PO透传所有层。并不需要VO.但一些特定的项目还是需要的,就如我所说的：为什么要用DTO（VO）。

我往往会找一些工具，或者自己扩展一些插件来完成这样的转换
比如 pojo对象转换成dto对象 我运用到了beanutils和注解形式自己写了个工具，转换也只是一行代码而已

User user = ......
UserDTO uDTO = MyBeanUtils.convert(user,UserDTO.class);
List<User> userList = .....
List<UserDTO> userDTOList = MyBeanUtils.convertList(userList,UserDTO.class);