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

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

 

Peter Wei

引子：

前两天，在内部讨论中。公司有一开发人员向我抛出问题：我们Web层和App应用层用DTO(VO)对象，没有直接用PO，你有什么好的建议？我自然知道他说这句话的意思，PO到DTO(VO)的不停转换，太麻烦，增加太多工作量了。因为我是负责做架构的，他是想让我向上面CTO反映取消掉DTO对象。但现有的架构是原先就有的，而且在一定程度上，我也认为需要用DTO对象。所以最终没有全部取消。


概念扫盲

我们现在大多数的应用，我想都是基于分层架构的：
Web层（Struts2 or SpringMVC等）App应用层（Service）Dao层(ORM)DB

PO:也就是一般概念上的Domain Object，如hibernate 中的Entity.一般用于Service层--Dao层间的数据传输。

DTO（VO）：也就是一般意义上的VO，封装后的对象。一般用于Web层—Service层间的数据传输入。

VO(DTO) VS PO
引子中开发人员是想用PO透传所有层。也就是共用PO，然后取消掉DTO。

1.PO透传的代码示例：

比如有一个Order的hibernate entity.
我们假设Order下还有Account等好几个对象和集合。

Java代码  

1. public class