开发规范-DTO和VO

DTO和VO的区别

DTO 是展示层和服务层之间传递数据的对象，为什么还需要一个 VO 呢？在绝大部分场景，DTO 和 VO 的属性值是一致的，通常都是 POJO，这只是实现方面的思维，但是在设计层面来说，概念上还是应该存在 DTO 和 VO 的，因为两者有本质的区别，DTO代表服务层需要接受的数据和返回的数据，而VO代表表示层需要展示的数据。
示例：
Service 有一个函数 getUser() 返回一个系统用户，其中有一个属性 gender(性别),对于Service层来说，它只是从语义上定义：1-男、2-女、0-未指定，对于展示层来说可能需要用到“帅哥”、“美女”、“秘密”来代表。
当这个服务供多个不同的客户端使用的时候，而且不同的客户端对于表现层的要求有所不同，就需要VO了

DTO和VO的应用

• DTO和VO只保留一个
  当需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，Service层的职责依然不应该与View层耦合，所以，对于前面的例子，你很容易理解，DTO对于“性别”来说，依然不能用“帅哥美女”，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS）
  即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐
• DTO和VO都需要保存
  因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。

如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装（当然，这同样可以通过服务层提供一次性返回一个大视图的DTO来取代，但在服务层提供一个这样的方法是否合适，需要在设计层面进行权衡）。