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

public class OrderAction{
	private Order order=new Order();
	private List<Order> orderList
	public String add(){
		orderService.add(order);
		return xx;
}

public String query(){
	orderList=orderService.find(Object param);
	return xx;
}
}

public class OrderService{
	
	public void add(Order){
		orderDao.saveOrUpdate(Order o);
}
	public List find(Object param){
		return orderDao.find(Object param);
}
}

2.用VO(DTO)模式的代码示例：

public class OrderService{
	
	public void add(OrderVO vo){
		Order order=new Order();
		Account account=new Account();
		
		account.setXX(vo.getXX);
		//一堆XX
		order.setAccount(account);
		//又一堆XX
		orderDao.saveOrUpdate(Order);
}
	public List<OrderVO> find(Object param){
		List list=orderDao.find(Object param){
			for(xxxx){
			//集合下的集合
			//更多的XX转换
			setXX
			setXX
}
}
}
}

PO的透传的优点一目了然，就是不用进行大量的数据对象转换，极大的减少开发人员的工作量。而且大多数PO和VO是重合的，属性什么都一样。我们知道虽然有BeanUtils等工具进行自动转换，但依然很繁琐。

BeanUtils.copyProperties(desc,src);

为什么用VO（DTO）

我在以前的工作过程中做过各种企业应用还有网站应用。大多数的项目，我们都用的是PO透传View,Action,Service,Dao层。但有两个项目中没用。

1.一个是联通的某OSS系统，该系统的基本技术架构是这样的：
Flex（Web层）BladeDSBusiness Facade(DTO)Service(Spring)Dao(hibernate)

我们一眼看出这是一个分布式的系统。也就是Flex和Java应用通迅的异构系统。在Flex和Java应用之间用DTO模式结合外观Facde模式就顺理成章，水道渠成了。为什么呢？因为两个进程间的通迅，复杂层级的Hibernate Domain Object不好直接传到Flex端，因为是用remote协议传输。Hibernate的lazy特性以及序列化都是个问题。所以加一个外观层进行PO到DTO的传输就很有必要了。

2.一个是一个电子商务网站，网站的基本技术架构是这样的：

有两部分，一部分是内部管理核心系统：
Flex应用Hessian Remote协议App Service(Sring)Dao(hibernate)

另一部分是电子商务系统，也就是对外的部分
Web应用（Jstl,jsp,SpringMVC）Hessian Remote协议 App Service(Sring)Dao(hibernate)

其中Flex应用单独部署一个工程，Web应用单独部署一个工程，App Service和Dao又部署一个工程。Flex和web应用都是单独通过hessian协议访问App应用。

我们来总结一下为什么要用DTO：
1. JavaEE各层之间解耦，这是从设计角度来说的。也就是说Domain Object(PO)直接封死在Dao层。高内聚，低耦合是我们追求的一个目标。但由于在一般的应用中大量的PO,VO转换，增加了工作量，也有些人说是过度设计。
2. 隔离变化。当在一些大型的应用场景以及Domain经常变化的系统里，View层可以只关注DTO对象，不用关心Domain层PO对象，如hibernate entity的不断变化。
3. 利于发挥个人技术特长，特别是按层来分工开发的团队。如有人专注于Web层，只做SpringMVC和界面这部分。还有人专门做Spring和Hibernate部分。两组的开发人员定义好接口数据就行，也就是DTO（VO）。我们当时做的电子商务网站就是这样的。
4. 当系统发展大后，扩展成各种前端界面后，可以有效隔离核心应用层。如又有web界面，又有swing的cs界面，又有手机客户端。
5. 当分层部署时，也就是Web层(jsp,Struts2)和App层(Spring,dao)在不同机器上时，用Remote协议通迅，DTO是必需的。如处理hibernate lazy load和序列化等问题。在电子商务应用中分层部署的主要好处是减少各层负载量，提高性能。
6. 在一些特定场景，如需要防火墙的地方，需要把核心数据层(Service,Dao,DB)放在防火墙内。

小结
综合以上所述，我认为VO（DTO）模式还是必需的，特别是考虑到以后扩展性的问题。但是在我们的团队中为了开发进度和避免对以前开发的功能影响，没有强制要求在Action和Service层间一定用DTO.但是新开发的功能模块要求用DTO模式，算是一种折中吧。以后系统大了之后再重构好了。要不然以后怎么有事做呢？哈哈。而且boss有时间压力在那。毕竟现在还没打算分层部署，够用就行，先不过度设计了。

其它牛人的一些观点：
参考：Martin Fowler的POEAA(企业应用架构模式)中分布式模式中的Remote Facade模式和DTO模式。

Rod Johnson在J2EE without ejb中是反对用DTO的。

欢迎拍砖，谢绝漫骂！

评论

38 楼 peterwei 2011-04-25  

accphc 写道

peterwei 写道

分离的北极熊 写道

互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……

愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。

说别人悲惨，或者你是大牛不屑于别人的讨论，说出你的观点。让后来人也继续学习进步！

说是大牛，只是客气。他不说观点，我就是bs了。

37 楼 peterwei 2011-04-25  

Cindy_Lee 写道

有时需要传输像json，xml这样的数据类型到页面，这个时候用pojo转换明显不合适
（比如用hibernate时pojo转换json就会报错，某些日期格式需要做特殊处理等）我通常会创造一个中间对象（vo，dto）来负责传输或者转换。这样的转换肯定是有消耗的，不过如果不是特别注重性能的情况下，这种消耗是可以忽略，一切为了开发简单，层次清晰

这种消耗，基本可以忽略不计。

36 楼 peterwei 2011-04-25  

<div class="quote_title">skzr.org 写道</div>
<div class="quote_div">
<div class="quote_title">peterwei我不是说你的观点有问题，感觉就是太<span style="font-size: medium; color: #ff0000;">学院派</span>了，我把我的观点标红了，我们应该<span style="font-size: medium; color: #ff0000;">关注业务设计</span>，其实很多时候所谓的po一样可以分布式，hibernate的延迟加载，我一直不用的，因为dto只是<span style="font-size: medium; color: #ff0000;">实现业务的手段</span>，这东西因为其运行时特性，故在业务设计中往往会带来不可预知的问题。</div>
<div class="quote_title">peterwei 写道</div>
<div class="quote_div">
<div class="quote_title">skzr.org 写道</div>
<div class="quote_div">
<p>我做企业应用的，以前也听某某、某某谈论dto、vo、po甚至其他oo。<br>我认为最佳的实践：楼下两个基本上讲的是原则。</p>
<p> </p>
<p> </p>
<div style="color: #000000; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; background-color: #ffffff; margin: 8px;">
<div class="quote_title" style="font-weight: bold; margin-top: 5px; margin-right: 0px; margin-bottom: 0px; margin-left: 15px; padding: 5px;">yangyiqian 写道</div>
<div class="quote_div" style="margin-top: 0px; margin-right: 5px; margin-bottom: 5px; margin-left: 15px; background-color: #fafafa; padding: 3px; border: 1px solid #cccccc;">首先我想说“存在就是真理”，DTO、PO绝对不是一个范畴的概念，<span style="color: #ff0000;">DTO!=PO</span>，所以也就谈不上谁代替谁的概念。当然了，你非要说老板就不能做员工的话吗？当然可以，不过这是做事的规矩吗？！<br><br><strong>一、DTO与PO的不对称关系决定了二者不能互相代替</strong><br>DTO与PO存在在映射关系，可能是多对一，也可能是一对多，最特殊的关系就是上面大家说的这种情况“一对一”。也就是在“一对一”的情况下可以实现DTO与PO的混用，而其他情况下，如果混用都需要PO进行冗余设计，考虑这些冗余设计会比直接的、简单的造一个新的DTO出现要耗费更多的脑细胞，同时这个东西又不利于后期维护，可以说“牵一发，动从上到下”。<br><strong>二、性能上决定了PO代替DTO是个蹩脚的设计</strong><br>PO是与数据库直接交互的对象，比如我要在页面上显示数据库中的数据，如果用PO来实现那么这个PO就得一直保持与数据库的连接，直到数据显示到页面上来。这样如果在service层有复杂运算的话，那么数据库方面的延时是非常可观的，而如果转换成DTO之后，数据库连接就可以尽快释放。所以从性能上来说应该使用DTO－－当然对于性能不是很苛刻的情况下不用DTO也行 －－不过，熟练的程序员应该养成按统一的方式做项目的习惯，我觉得这样会更高效。<br><br><br>
</div>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">最佳实践：</p>
<p style="margin: 0px;"><span style="color: #ff0000;">软件是发展的，<span style="font-size: medium;"><strong>我只认设计中的bean，如果bean要持久化就有po的职责了，一切都只是手段而已</strong></span></span></p>
<p style="margin: 0px;"><span style="color: #ff0000;"><br></span></p>
<p style="margin: 0px;"><span style="line-height: 18px; font-family: Arial, sans-serif, Helvetica, Tahoma;"><span style="color: #ff0000;">难道是ORM把我们绑架了！太在意po和dto这样的概念了，设计才是根本，满足设计的bean才是核心。</span></span></p>
<p style="margin: 0px;"><span style="color: #ff0000;"><br></span></p>
<p style="margin: 0px;"><span style="color: #ff0000;">就正如时刻要记住的技术是为了实现业务需求而用，很多人反过来用了，为了技术而技术，被技术忽悠。最简单、是人就可以看懂的实现才是好实现</span></p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;"> </p>
</div>
</div>
<p> 我也说了，大多数的企业应用，是可以po从view-dao透传所有层的。但是一些特定场景，特别是分布式环境，异构环境，DTO模式还是很有必要存在的。PO和DTO的概念还是很有必要理清的。很多东西，由于个人的一些经验问题，接触得不多，往往很难一眼看清本质。特别是底层的人员，有时候会看不清楚一个设计为什么这样。所以我觉得讲讲，扫下盲是有必要的，特别是对团队内部的人来说。而不能什么都不让他们知道，只是强制执行。</p>
</div>
<p> </p>
</div>
<p>  我们是只关注业务设计呀。正因为有那样的业务场景，所以才有我说的那两个特别的项目用dto的。而大多数都用po透传。在有remote的业务场景里，dto还是必需的。所有的技术都是实现业务的手段，这点是没有什么疑问的。就看哪种技术适合哪种场景，还有我们在进行架构设计时的取舍。如dto模式可以利于以后的扩展性，但如果不用也是行的，等以后再重构好了。dto并不会在开发中带来不可预知的问题。我认为唯一的缺点就是，大量的dto-po,po-dto的转换,增大了工作量而已。</p>

35 楼 lookdd1 2011-04-25  

从另一篇帖子得知楼主是搞互联网的。。。。

把这个了链接发给LZ 仔细看看吧


http://gettingreal.37signals.com/GR_chn.php

34 楼 accphc 2011-04-25  

peterwei 写道

分离的北极熊 写道

互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……

愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。

说别人悲惨，或者你是大牛不屑于别人的讨论，说出你的观点。让后来人也继续学习进步！

33 楼 accphc 2011-04-25  

我觉得一个系统一个模块是否有必要写一个VO得看具体的情况吧。对于一个VO可能包含多个PO的情况那肯定需要VO，如果你的VO和PO一模一样，你还要弄个转化，这不是蛋疼没事干啊？难道是为了系统统一这么做，或者所谓的以后方便扩展？

32 楼 分离的北极熊 2011-04-25  

peterwei 写道

分离的北极熊 写道

互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……

愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。

笑而不语~~

31 楼 Cindy_Lee 2011-04-25  

有时需要传输像json，xml这样的数据类型到页面，这个时候用pojo转换明显不合适
（比如用hibernate时pojo转换json就会报错，某些日期格式需要做特殊处理等）我通常会创造一个中间对象（vo，dto）来负责传输或者转换。这样的转换肯定是有消耗的，不过如果不是特别注重性能的情况下，这种消耗是可以忽略，一切为了开发简单，层次清晰

30 楼 skzr.org 2011-04-25  

<div class="quote_title">peterwei我不是说你的观点有问题，感觉就是太<span style="color: #ff0000; font-size: medium;">学院派</span>了，我把我的观点标红了，我们应该<span style="color: #ff0000; font-size: medium;">关注业务设计</span>，其实很多时候所谓的po一样可以分布式，hibernate的延迟加载，我一直不用的，因为dto只是<span style="color: #ff0000; font-size: medium;">实现业务的手段</span>，这东西因为其运行时特性，故在业务设计中往往会带来不可预知的问题。</div>
<div class="quote_title">peterwei 写道</div>
<div class="quote_div">
<div class="quote_title">skzr.org 写道</div>
<div class="quote_div">
<p>我做企业应用的，以前也听某某、某某谈论dto、vo、po甚至其他oo。<br>我认为最佳的实践：楼下两个基本上讲的是原则。</p>
<p> </p>
<p> </p>
<div style="color: #000000; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; background-color: #ffffff; margin: 8px;">
<div class="quote_title" style="font-weight: bold; margin-top: 5px; margin-right: 0px; margin-bottom: 0px; margin-left: 15px; padding: 5px;">yangyiqian 写道</div>
<div class="quote_div" style="margin-top: 0px; margin-right: 5px; margin-bottom: 5px; margin-left: 15px; background-color: #fafafa; padding: 3px; border: 1px solid #cccccc;">首先我想说“存在就是真理”，DTO、PO绝对不是一个范畴的概念，<span style="color: #ff0000;">DTO!=PO</span>，所以也就谈不上谁代替谁的概念。当然了，你非要说老板就不能做员工的话吗？当然可以，不过这是做事的规矩吗？！<br><br><strong>一、DTO与PO的不对称关系决定了二者不能互相代替</strong><br>DTO与PO存在在映射关系，可能是多对一，也可能是一对多，最特殊的关系就是上面大家说的这种情况“一对一”。也就是在“一对一”的情况下可以实现DTO与PO的混用，而其他情况下，如果混用都需要PO进行冗余设计，考虑这些冗余设计会比直接的、简单的造一个新的DTO出现要耗费更多的脑细胞，同时这个东西又不利于后期维护，可以说“牵一发，动从上到下”。<br><strong>二、性能上决定了PO代替DTO是个蹩脚的设计</strong><br>PO是与数据库直接交互的对象，比如我要在页面上显示数据库中的数据，如果用PO来实现那么这个PO就得一直保持与数据库的连接，直到数据显示到页面上来。这样如果在service层有复杂运算的话，那么数据库方面的延时是非常可观的，而如果转换成DTO之后，数据库连接就可以尽快释放。所以从性能上来说应该使用DTO－－当然对于性能不是很苛刻的情况下不用DTO也行 －－不过，熟练的程序员应该养成按统一的方式做项目的习惯，我觉得这样会更高效。<br><br><br>
</div>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">最佳实践：</p>
<p style="margin: 0px;"><span style="color: #ff0000;">软件是发展的，<span style="font-size: medium;"><strong>我只认设计中的bean，如果bean要持久化就有po的职责了，一切都只是手段而已</strong></span></span></p>
<p style="margin: 0px;"><span style="color: #ff0000;"><br></span></p>
<p style="margin: 0px;"><span style="line-height: 18px; font-family: Arial, sans-serif, Helvetica, Tahoma;"><span style="color: #ff0000;">难道是ORM把我们绑架了！太在意po和dto这样的概念了，设计才是根本，满足设计的bean才是核心。</span></span></p>
<p style="margin: 0px;"><span style="color: #ff0000;"><br></span></p>
<p style="margin: 0px;"><span style="color: #ff0000;">就正如时刻要记住的技术是为了实现业务需求而用，很多人反过来用了，为了技术而技术，被技术忽悠。最简单、是人就可以看懂的实现才是好实现</span></p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;"> </p>
</div>
</div>
<p> 我也说了，大多数的企业应用，是可以po从view-dao透传所有层的。但是一些特定场景，特别是分布式环境，异构环境，DTO模式还是很有必要存在的。PO和DTO的概念还是很有必要理清的。很多东西，由于个人的一些经验问题，接触得不多，往往很难一眼看清本质。特别是底层的人员，有时候会看不清楚一个设计为什么这样。所以我觉得讲讲，扫下盲是有必要的，特别是对团队内部的人来说。而不能什么都不让他们知道，只是强制执行。</p>
</div>
<p> </p>

29 楼 peterwei 2011-04-25  

分离的北极熊 写道

互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……

愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。

28 楼 peterwei 2011-04-25  

jansel 写道

其实有的时候不是技术决定的，而是由部门决定的

比如我们现在，我们这个项目做后台逻辑，以及业务逻辑

另外一个部门的项目组做页面，那此时肯定会有VO，这个就不是技术要求了，而是避免两个部门扯皮

如果是一个项目组搞定的话，我个人认为是不需要VO的，VO这个东东太鸡肋了，弊大于利。

这个就是我说的分层分团队开发一定是需要vo做为接口数据的。

27 楼 分离的北极熊 2011-04-25  

互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……

26 楼 blogaaa 2011-04-25  

明确了概念

25 楼 keqi24 2011-04-25  

yimlin 写道

vo和po的区别就不多说了。

vo的作用有两种：
1.模块隔离：对外暴露，屏蔽内部实现。
2.分布式支持：用于异步传输；

换句话说：
如果不打算进行严格的模块化/组件化，又没有分布式场景，就不应该使用VO。
如果不打算进行严格的模块化/组件化，但存在部分分布式场景，比如lz所说的flex，那么针对部分进行VO开发即可；

此外，决定是否启用VO除了上述两个作用对应的场景外，另有如下两个因数：
1.PO是否是Rich Model？
2.开发人员是按分层分工还是按功能分工？

如果PO是贫血的，且是按分层分工开发的那么应该启用VO，因为，由于后台模型变化导致前台的调整会带来沟通协调的成本；
如果PO是Rich Model，且是按功能分工，那么就不应使用VO，VO和PO只会趋近，最终带来更多的维护成本，且在Rich Model下只变后台不变前台的比率较低，大部分情况下，功能的调整/改进会同时影响前后台。

我个人也觉得VO应该视情况而定，没必要强制开发，有需求的时候再写就可以！

24 楼 jansel 2011-04-25  

其实有的时候不是技术决定的，而是由部门决定的

比如我们现在，我们这个项目做后台逻辑，以及业务逻辑

另外一个部门的项目组做页面，那此时肯定会有VO，这个就不是技术要求了，而是避免两个部门扯皮

如果是一个项目组搞定的话，我个人认为是不需要VO的，VO这个东东太鸡肋了，弊大于利。

23 楼 peterwei 2011-04-24  

yimlin 写道

vo和po的区别就不多说了。

vo的作用有两种：
1.模块隔离：对外暴露，屏蔽内部实现。
2.分布式支持：用于异步传输；

换句话说：
如果不打算进行严格的模块化/组件化，又没有分布式场景，就不应该使用VO。
如果不打算进行严格的模块化/组件化，但存在部分分布式场景，比如lz所说的flex，那么针对部分进行VO开发即可；

此外，决定是否启用VO除了上述两个作用对应的场景外，另有如下两个因数：
1.PO是否是Rich Model？
2.开发人员是按分层分工还是按功能分工？

如果PO是贫血的，且是按分层分工开发的那么应该启用VO，因为，由于后台模型变化导致前台的调整会带来沟通协调的成本；
如果PO是Rich Model，且是按功能分工，那么就不应使用VO，VO和PO只会趋近，最终带来更多的维护成本，且在Rich Model下只变后台不变前台的比率较低，大部分情况下，功能的调整/改进会同时影响前后台。

和我的想法完全一样。而且总结得比我简要。我们以后是要做模块化的，所以VO对于以后的扩展很有必要。同时以后有可能做web层和应用层的分布式。不是Rich Model,功能是贫血模型。

22 楼 peterwei 2011-04-24  

kimmking 写道

虽然话题太老了。
但是说的还是在理，投个良。~

话题是五六年前讨论过的。但是前辈们对于为什么要使用，什么时候使用DTO并没有说得特别清楚，也没有实例说明。他们只是在互喷。

21 楼 peterwei 2011-04-24  

hsiss 写道

dto直接用map代替不就行了吗,为了架构而架构

你根本就没弄清楚为什么用DTO模式。

20 楼 yimlin 2011-04-24  

vo和po的区别就不多说了。

vo的作用有两种：
1.模块隔离：对外暴露，屏蔽内部实现。
2.分布式支持：用于异步传输；

换句话说：
如果不打算进行严格的模块化/组件化，又没有分布式场景，就不应该使用VO。
如果不打算进行严格的模块化/组件化，但存在部分分布式场景，比如lz所说的flex，那么针对部分进行VO开发即可；

此外，决定是否启用VO除了上述两个作用对应的场景外，另有如下两个因数：
1.PO是否是Rich Model？
2.开发人员是按分层分工还是按功能分工？

如果PO是贫血的，且是按分层分工开发的那么应该启用VO，因为，由于后台模型变化导致前台的调整会带来沟通协调的成本；
如果PO是Rich Model，且是按功能分工，那么就不应使用VO，VO和PO只会趋近，最终带来更多的维护成本，且在Rich Model下只变后台不变前台的比率较低，大部分情况下，功能的调整/改进会同时影响前后台。

19 楼 peterwei 2011-04-24  

ltian 写道

扫盲者没有说清楚DTO和PO的职责，其他人也没有说到点子上。

我其实主要想说清楚的是为什么有些场景是需要DTO的。并不在于说DTO和PO的概念。