大家都知道，现在的企业级的系统中，因为业务的复杂性，在系统的设计上，通常都是会进行分层设计，在分层的过程中，需要对于输入和输出的对象根据实际的需要进行不同的定义，为了更好的描述实际的场景，下面给个实际的例子进行描述各种O的用途，提醒自己后续的研发过程中有个参考依据。
为什么要区分各种O对象呢，主要有下面几点吧：1、显得比较专业 2:、安全，控制信息传播的范围 3、减少没必要的信息传输带来的内存和宽带的压力 4、更能体现分层的价值和标准化。
例子：
最常见的一个场景，比如用户服务，用户服务中提供了如下的几个功能，用户注册，用户信息修改，用户登录，用户查询，用户数据同步到LADP等等。
那么按照之前讲过的一个比较标准和比较好的一个架构分层，我们会抽象至少提供2个应用。:一个是用户管理应用，主要是和界面交互入口应用和一个提供用户管理逻辑的微服务，如下图显示了VO,DTO,DO的主要用途
图一
按照上图的架构显示，可以看出
VO：ViewObject表现层传输对象,对应界面显示的数据对象。按照界面的显示输出要求和页面信息收集输入要求，设计出对应的VO对象。如果输入和输出是相同的，则使用一个VO对象，如果输入和输出不同时，一般会设计成2个VO对象，ReqVO和RespVO。
DTO：Data Transfer Object数据传输对象,正如名字的传输，所以，一般情况下DTO，就是用于做数据传输的，也就是通常情况下的接口交互中需要使用的。那么如果是系统内不同的层级之间的数据传输呢，是不是也是DTO呢？答案是一般不建议使用DTO。而是使用BO和PO。因为按照3层的结构来讲，一般就直接转成业务处理逻辑层需要的对象，或者持久化层需要的对象了。这样会减少系统的复杂性。
DAO:Data Access Object 数据访问对象,通常包含了DB的一些新增，删除，修改，查询等等操作的对象。这里的DAO更多的是指操作。
PO:Persistant Object持久对象,基本上和数据表中的字段一致，也是用来表示数据库的持久化的对象。
继续看一下，下面的架构和分层图
图二
BO：BO 是Business Object 的缩写，按照实际的业务需求而设计的一个业务对象。BO通常是包含了几个需要进行持久化的PO对象的信息，或者BO包含了几个需要返回出去的VO或者DTO对象。
最后讲一下：几个层级直接的方法一般定义方式：
UserController:
List<UserVo> list(UserVo);
String addOrModify(UserVo);
UserApiService:
List<UserDTO> list(UserDTO);
String addOrModify(UserDTO);
UserSerivce:
UserBo list(UserBO )；
String addOrModify(UserBO );
UserDao:
List<UserPO> list(UserPO);
String addOrModify(UserPO);
UserWrapper;
change(UserVo,UserBO)
change2(UserBO,UserPO)
change3(UserDTO,UserBO)。
写在最后：
软件体系中，没有完全的对或者错，应该或者不应该，仅仅是个人偏好导致每个人对相同问题解决方案的不一致。
欢迎大家留意讨论，共同进步。
网友评论