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 OrderAction{   
  2.     private Order order=new Order();   
  3.     private List orderList   
  4.     public String add(){   
  5.         orderService.add(order);   
  6.         return xx;   
  7. }   
  8.   
  9. public String query(){   
  10.     orderList=orderService.find(Object param);   
  11.     return xx;   
  12. }   
  13. }   
  14.   
  15. public class OrderService{   
  16.        
  17.     public void add(Order){   
  18.         orderDao.saveOrUpdate(Order o);   
  19. }   
  20.     public List find(Object param){   
  21.         return orderDao.find(Object param);   
  22. }   
  23. }  
public class OrderAction{
	private Order order=new Order();
	private List 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)模式的代码示例:

Java代码 复制代码  收藏代码
  1. public class OrderService{   
  2.        
  3.     public void add(OrderVO vo){   
  4.         Order order=new Order();   
  5.         Account account=new Account();   
  6.            
  7.         account.setXX(vo.getXX);   
  8.         //一堆XX   
  9.         order.setAccount(account);   
  10.         //又一堆XX   
  11.         orderDao.saveOrUpdate(Order);   
  12. }   
  13.     public List find(Object param){   
  14.         List list=orderDao.find(Object param){   
  15.             for(xxxx){   
  16.             //集合下的集合   
  17.             //更多的XX转换   
  18.             setXX   
  19.             setXX   
  20. }   
  21. }   
  22. }   
  23. }  
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 find(Object param){
		List list=orderDao.find(Object param){
			for(xxxx){
			//集合下的集合
			//更多的XX转换
			setXX
			setXX
}
}
}
}


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

Java代码 复制代码  收藏代码
  1. BeanUtils.copyProperties(desc,src);  
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的。

欢迎拍砖,谢绝漫骂!

你可能感兴趣的:(设计模式,系统架构)