项目中的 DO、DTO、BO、VO、POJO的区别是什么
概述
这篇文章主要讲解了“java中DO、DTO、BO、VO、POJO的区别是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“java中DO、DTO、BO、VO、POJO的区别是什么”吧！
定义
先来看看阿里巴巴开发规约的定义： POJO（Plain Ordinary Java Object）：在本规约中，POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。
【参考】分层领域模型规约：
- DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
- DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
- BO（Business Object）：业务对象。可以由Service层输出的封装业务逻辑的对象。
- Query：数据查询对象，各层接收上层的查询请求。额外规定：【强制】超过2个参数的查询封装，禁止使用Map类来传输。
- VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。 —《阿里巴巴Java开发规约》
再以学生档案管理系统为例，我们现在需要做个学生档案管理的后台系统，按照上面的定义，我们能定义出以下一些对象: 如下图所示：
DB层这里应该叫存储层，这里只列了DB，还有类似HBase、Redis，泛指储存数据。
以Student表为例，DB层负责存储。
- DAO层提供了查询、删除、写入的接口；
- DO 就是DAO操作的对象，这里是StudentDO，有时候也会省略DO，直接写Student；
- service层或core层是做业务逻辑处理的，比如查询接口，根据学生学号调用DAO层获取Student信息，之后做一次数据裁剪，只取业务字段，例如版本号、自增id、数据库记录创建时间等非业务字段不取，获取一个StudentDTO，然后查询学生档案相关的ProfileDTO，组装成ProfileBO，作为档案领域模型；
- 业务层从service 层拿到这个BO，对BO做一个视图转化，转成VO视图对象，提供给前端负责展示。
- 大学刚毕业实习那会写了一个业务层直接调用DAO层的代码，觉得中间要经过服务层、核心层过于繁琐，字段都差不多，后面被Team Leader 教学了。
- VO（视图） 和 DO（数据模型）都可能会随着需求变化，软件设计的原则是降低耦合，一杆到底这种设计就是强耦合（把视图和数据直接绑定），DO变化的时候因为DTO（数据传输对象）、BO（领域模型）的存在，不需要修改VO，VO修改也同样不需要修改DO数据模型。
飞哥解说
根源的开始DO
在实际的开发和工作中，我们项目的核心和根本还是MVC。经典的不能在经典了。这也是根本也是根基。其中我们开发中的:Bean 也就是上面的Student.java, 在很多的术语中你可以理解成为：Bean,Model，Domain,DO,Pojo其实说的都是一回事。
- DO(bean,model,pojo,domain)都是指直接和数据库表的列映射的一层。问题的根源也在这里，演变的路程也是从这里开始。
开始演变之路
问题1
任何的改变和扩展肯定是之前的架构出现了问题或者带来了维护的不变，所以需要扩展。要不然改它干嘛。你们说对不对？ 我们在开发中，经常为了达到一些业务和扩展一些功能，肯定是很平常和正常的事情，我们为了方便可能就直接会去修改DO（bean,model,pojo）层，会在这个类中去增加额外的属性。救命啊。这就破坏了数据结构了。 但是很多的框架比如hibernate,mybatis都做了很多这方面处理。就是把一些字段增加一些忽略即可。来代表这个字段不是数据库表的列。也不需要和数据库表打交道。但是问题也很明显。本来我是一个孑然一身的类，干干净净的，但是为我了达到某个功能不得不污染。就会造成类的污染，为了解决这个问题，引入了BO/DTO
问题2：
在前端的交、互过程中，我们经常会出现一个问题就是，界面上form表单或者异步请求的参数很多时候会少于DO（bean,model,pojo）类的字段。比如登录，注册，可能数据库字段有30个，但是页面只需要用户填写的就10个或者8个就可以了。就可以实现功能。大部分实现的方式就是直接怼DO（bean,model,pojo）.把他们当做参数来进行接收客户端form或者ajax传递过来的数据。因为方便，如下代码
#伪代码
public int saveUser(User user){
// 直接使用user来进行注入，但是其实user有30个属性，但是界面上传递过来的可能就10个或者几个。
}- 而且现在很多的测试工具比如：swagger可以反射读取参数所有的属性，对于接口的调用者来说是透明的。这样就很不安全。可以看到实体和数据库的所有的字段。
- 对于接口的调用者，很多时候你给接口的调用这所有的属性，他们会觉得很突兀，觉得是不是需要所有的字段都要进行填写。就会造成调用过程的认知和沟通成本
所以这个时候VO诞生了。使用VO专门来解决 视图层和业务层的参数的接受问题，这样的方式是一个萝卜一个坑的方案，也可以很好的保护对实体属性的暴露。是一种非常优雅的机制。这样调用者也不用去关系其他的字段了。
问题3：
在开发中，为啥返回的时候，我们都喜欢用BO或者DTO返回呢？而不是使用DO(model,pojo,bean)返回呢？其实和上面的问题是一样，一种按需选择的问题，在开发中，返回整个实体是不安全的，会暴露很多不需要的字段出去，让用户得知。所以BO/DTO就是为了解决这个问题应运而生。让返回的数据也能够按需选择，甚至可以改写。这样就可以很好的保护DO数据库的字段列。
那为什么有了BO还要有DTO呢？
- BO对外
- DTO对内
整个架构图解说上面的问题
总结
- 其实不论是VO，还是BO/DTO都是为了保护DO不对外暴露的问题，这样不直接操作，而是利用一种扩展的方式从而进行数据的交换，让开发和流程上更加清晰而已。任何东西的选择都是按需选择返回(BO/DTO)和按需传递给服务端(VO)。当然这样也更利于你对代码和项目构建的理解。
- 另外一句话：如果项目很小，不大，其实也不建议弄这么多层，但是如果是企业级的项目尽量使用，从长远的思考是有利的。
- 架构不是一层不变，能够解决你当下业务并且持久的发展，这种架构才是最好的架构，而不能去盲目的追求，毕竟这些都是人为指定和规范出来的标准。如果你觉得不合适也可以推翻，也可以改造。但是不能盲目的认为这就是标准
