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层）BladeDSBusiness 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的。
欢迎拍砖，谢绝漫骂！
分享到：
.我当时查了一些网上的资料。需要自已对hibernate lazy以及序列化做处理才能避免恶心的lazy。
相关推荐
### Java中的PO、VO、TO、BO、...PO、VO、TO、BO、DAO与POJO各自在系统架构的不同层次中扮演着不同的角色，相互之间既有联系又有区别。理解这些对象的概念及其应用场景，有助于我们在开发过程中做出更合适的设计选择。
java简单基础 需要的了解一下 我们大家还是有必要去区分的
在软件开发中，视图对象（View Object，简称VO）和数据传输对象（Data Transfer Object，简称DTO）是两种常见的设计模式，它们在系统架构中起着至关重要的作用。这两种对象主要用于解决数据模型与界面展示之间的数据...
DTO（Data Transfer Object）设计模式是一种在分布式系统中广泛使用的设计模式，它的主要目的是为了在系统组件之间传递数据。在大型应用程序中，特别是在服务层和表示层之间，DTO扮演着重要角色，因为它们能有效地...
然而，对于VO对象、DTO对象以及前端Vue页面等非预置的代码生成需求，就需要我们对默认的代码生成器进行扩展和定制。 在MyBatisPlus 3.5.3版本中，代码生成器主要有两种类：`AutoGenerator`和`FastAutoGenerator`。`...
本文将详细解析"PO/POJO/VO/BO/DAO/DTO"这六个概念，并探讨它们在实际项目开发中的作用和应用场景。 1. PO（Persistent Object，持久化对象） PO是指与数据库表结构一一对应的Java对象，它通常包含了数据库表中的...
Java中 PO VO BO DTO DAO 和 POJO 关系图
在现代软件开发中，特别是Java企业级应用开发中，为了更好地实现系统解耦、提高可维护性和可扩展性，经常采用分层领域的模型来组织代码。本文将详细介绍VO (View Object)、DTO (Data Transfer Object)、BO (Business...
在微服务架构中，DDD分层模型依然适用，但需要进行微调整以适应服务边界。每个微服务可以看作是一个独立的业务领域，拥有自己的用户接口层、应用层、领域层和基础层。微服务的一级目录结构通常按照DDD的四层模型划分...
在Java开发中，我们经常会遇到各种各样的对象类型，这些对象有着特定的用途和命名约定。以下是关于POJO、VO、PO、DO、DTO...在实际开发中，根据项目需求和设计原则灵活选择和应用这些概念，能提高代码质量和可扩展性。
J2EE基础知识之DTO,VO,PO,DO等定义J2EE基础知识之DTO,VO,PO,DO等定义J2EE基础知识之DTO,VO,PO,DO等定义
在本文中，我们将深入探讨如何使用C#.NET 8创建一个Web API，同时结合SqlSugar作为ORM工具，以及实现仓储模式、DTO（Data Transfer Object）转换、服务层和服务控制层的架构设计。这个综合应用旨在提供一个高效且可...
在软件开发过程中，数据传输对象（Data Transfer Object, DTO）是一种常见的设计模式，用于在系统之间传递大量数据。DTO不包含任何业务逻辑，主要是数据容器。在这个场景中，"快速生成DTO"指的是利用Excel模板来自动...
在IT行业中，DTO（Data Transfer Object）是一种设计模式，用于在系统之间传递数据，它将业务逻辑层与表现层的数据解耦。标题“分页dto把html写在dto里”和描述“把分页按钮写在dto里，其他dto继承他”表明了一个...
DTO设计模式已被广泛用于JavaEE项目中，尤其是在那些使用EJB，SOAP，REST等技术的项目中。讨厌编写DTO类并将这些值转换为Bean并反之亦然的开发人员。使用此API有一些简单的步骤，并将提到一些重要的注释。您所需要的...
DTO 模式或称 VO 模式，是指将数据封装成普通的 JavaBeans，在 J2EE 多个层次之间传输。DTO 类似信使，是同步系统中的 Message，该 JavaBeans 可以是一个数据模型 Model。 五、数据建模 数据建模是指将数据封装成 ...
DTO，全称Data Transfer Object，是软件设计模式中的一种，主要用在分布式系统或Web服务之间，用于数据的传输。DTO对象通常不包含任何业务逻辑，仅仅是数据的载体，使得不同层之间的数据交换变得简单。在这个"登陆的...
数据库表转实体类和DTO是软件开发中一个常见的任务，特别是在Java后端开发中，它涉及到数据模型的设计和数据访问层的操作。实体类（Entity Class）通常代表数据库中的表，而DTO（Data Transfer Object）则用于在不同...
设计模式是经验丰富的开发者在实践中总结出的最佳实践，被广泛应用于J2EE多层系统架构中，包括架构设计、框架以及多种设计模式的组合。 GoF设计模式，即Gang of Four设计模式，由《设计模式：可复用面向对象软件的...
PO可以严格对应数据库表，一张表对映一个PO。... VO：value object值对象、view object视图对象 PO：持久对象 QO：查询对象 DAO：数据访问对象——同时还有DAO模式 DTO：数据传输对象——同时还有DTO模式