VO&BO&DTO闲谈

首先写在开头，所有的分层规范并不是标准，只与个人或者团队项目规范为准，所以本文谈到的也只是个人理解。

DTO （Data Transfer Object）数据传输对象

当前端需要向我们的服务端传送的大量的数据的时候，一般在java中会专门定义一个类去接收这样一个json对象。
（当然也可以不定义这样一个类也是能接收到的）这些个类一般叫做DTO。

这样做的好处有如下三点：

第一，你不需要任何文档，直接查看DTO类就知道前端会传什么过来。
第二，你在取值的时候，是通过调用对象方法来取值，这可以避免你写错字段名，比如在koa里面，我们需要ctx.get(‘body.name’)，或者PHP的$POST[‘name’]。
第三，和第二点有点关联。假设我们有个接口，已经运行了好几年，突然有一点，我有一个字段名改了，很不巧，这个DTO同时给几个接口方法复用了。这时候就麻烦了。按照动态语言的工程，我需要找到所有用了这个表单数据的接口，把那个名字改一遍。如果我们有DTO,就不一样了。我们直接在DTO类上打个注解，手动指定下新的字段名，那么调用的地方，全部不用改动。
是不是很棒！
其实我觉得很多编码优秀啊什么的，看代码应对改变的方法就能区分出这个代码的优秀与否。其实我觉得就是考验一个程序员的预判能力，不是有句话说的好“不会偷懒的程序员不是好程序员”，不管是写配置文件还是干嘛干嘛，我觉得最本质的目的就是尽可能的只去改动少的地方，将变化放到最开始的地方，将变化隔离到一个地方。

VO （value/view object）值对象/视图对象
当服务端同学开发完成之后，通常情况下是，需要向前端返回json格式的数据对象。但是在很多情况下我们又不能直接将model层查出来的原封不动的返回给前端同学的，这个时候需要我们定义这样一个类去封装返回数据，这个类是随着我们前端同学的需求改变而改变的。

这样的好处：
前端的需求是千变万化的，今天不需要返回某个字段，可能明天就需要用到了，我们既不能完完全全的按照前端的需求按需返回，也不能将数据库中全部涉及到的字段信息完全返回，我们能做到的就是尽可能的寻求到平衡点，达到既能满足前端同学的需求，又不需要做到频繁的改动。java中出现这个层的原因我觉得主要是因为java不是动态语言，对于对象的属性精简这块做的没有动态语言那块优秀，所以才出现了这样一个层专门来解决这个问题的。

BO （business object）业务对象

很多情况下我们需要写一些小的能够复用的方法，然后去返回一些数据，在java中我们一般会使用类去组织这些数据对象（很多情况下是否需要用到类去组织数据与数据的数量没有很大的关系，也可以直接在本类中直接构建这个数据对象，但是随着业务的越来越复杂，这个本类会变得十分臃肿），这个时候我们会发现这个类不知道放到哪里合适，为了解决这个问题，BO衍生了。这个类，就是BO类，存放各种BO类的目录,就是BO层。

BO是一种概念,不用局限于就是返回一种特定语言的对象,这里的对象,就是一个抽象的概念,并不具体指什么，可以理解成需要返回一个完整的东西。

就是为什么会诞生BO类，从另一个角度来说，BO类其实就是用来生成复杂的业务数据对象,因为我们不方便把这些实现放到现有的service类中，所以独立出来的概念。

如果你不想一个类的职责过多，你肯定会想到要去独立出一个类来专门做这件事情。BO类就是具体的实现，只不过他还有一个要求，就是带了业务性质。

业务这个概念很泛的,在软件工程里面，凡是你要实现某个功能，其实都叫业务，绝大多数业务都需要依赖数据，BO就是专门封装这些业务数据。

举个例子
当我们想要往数据库里面插入一条完整的记录的时候，涉及到这条记录的全部的字段信息可能分散到各个地方，这个时候我们就需要用一个方法将这些字段信息拼凑成完整的一条记录，方便我们可以直接写入数据库，这个时候我们就可以封装一个BO。

BO解决了数据封装的问题，这个是主要职责。还有一个基础的职责，就是我们刚刚说到的分层的初衷，隔离变化。

接上面的那个例子，在真实的场景中，可能后续的业务流程还需要用到这个BO，所以这也是为什么有很多资料说BO在服务层之间传递的原因。因为BO带有业务性质，并不是单一的为了某个service去服务，而我们封装BO也是为了一定程度实现复用。只要这个service需要用到这些业务数据，那么就可以直接使用这个BO。