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等好几个对象和集合。

 .我当时查了一些网上的资料。需要自已对hibernate lazy以及序列化做处理才能避免恶心的lazy。 .我当时查了一些网上的资料。需要自已对hibernate lazy以及序列化做处理才能避免恶心的lazy。


简单的POJO，搞一个Lazy太高了，有时候还需要控制并行安全，哎～。

    91 楼    LSQ6063    2011-04-27              说实在的，如果系统不是做服务化，就通吃吧。    92 楼    fuyaner    2011-04-28              LSQ6063 写道说实在的，如果系统不是做服务化，就通吃吧。
我也觉得透传好。一般现在企业里的应用，有谁会去搞remote.过度设计吧你们。    93 楼    mqlfly2008    2011-04-28              学习了！知道了回报和付出，剩下的就是权衡的艺术了！虽然做的是小系统，但因为一直不希望修改数据库映射（po），所以每次都去包装一个vo来做！当然vo有很多组合po或或者是相互继承！呵呵！最后感觉还是乱了！但一直坚定的认为vo是必须的！只是如何去建立vo和如何解决vo和po间映射的问题上思考    94 楼    抛出异常的爱    2011-04-28              mqlfly2008 写道学习了！知道了回报和付出，剩下的就是权衡的艺术了！虽然做的是小系统，但因为一直不希望修改数据库映射（po），所以每次都去包装一个vo来做！当然vo有很多组合po或或者是相互继承！呵呵！最后感觉还是乱了！但一直坚定的认为vo是必须的！只是如何去建立vo和如何解决vo和po间映射的问题上思考
这就是为什么 需要规范
一开始好弄
后来就乱七八糟了.    95 楼    peterwei    2011-04-28              抛出异常的爱 写道mqlfly2008 写道学习了！知道了回报和付出，剩下的就是权衡的艺术了！虽然做的是小系统，但因为一直不希望修改数据库映射（po），所以每次都去包装一个vo来做！当然vo有很多组合po或或者是相互继承！呵呵！最后感觉还是乱了！但一直坚定的认为vo是必须的！只是如何去建立vo和如何解决vo和po间映射的问题上思考
这就是为什么 需要规范
一开始好弄
后来就乱七八糟了.
规范还是很重要的。    96 楼    zhaotao_king    2011-05-05              学习了！~~~
加深了~~~~呵呵    97 楼    fengfeng925    2011-05-17              在一些分布式开发中，很多数据是通过mc服务读取出来的，这个时候并不需要将数据存到本地，只要读取服务即可，最简单的一个例子，显示在view上的数据，一部分是你本地库中的，其他一部分是通过mc服务读取出来的，这个时候，必须要用到DTO。