为什么使用VO，DTO，BO

一、VO（View Object）

Vo顾名思义是一个有关视图的对象，主要应用于与前端之间的交互。Vo通常封装了前端调用某个接口之后，他所需要的所有的数据。Java具有面向对象的特点，但在这个前后端分离的时代，“对象”的定义，不仅仅是一个一个的类，而转变为一个又一个的接口。对于前端而言，他所面向的对象，便是后端提供的接口，而接口对象怎么去表示呢，我们选择使用返回对象的含义+Vo去创建实体类，来表示他是一个视图层的类。

二、DTO（Data Transfer Object）

Dto是相对于web网站中，前后端而言的“数据传输层”所需要的对象。Dto主要应用于以下几处：

在Controller层，接口传参使用Dto对象来进行接收，无论参数个数多少，就算只有一个参数，也应当创建一个Dto对象进行接收。有人会问，为什么不用@RequestParam来做，简单来讲，一是不美观，二是维护困难。当参数过多的情况下，接口的一个括号里，会掉满了各类注解，各类对参数的设定。其次，如果对于接口参数新增或者减少的情况来讲，接口参数的维护会很难受。而如果使用Dto传参，我的维护成本仅仅只是Dto这个对象。无论是新手老手还是谁来接手维护该接口，大家都很明确，我接口是用的Dto来接受的参数，那么我就只需要去研究Dto这个对象有哪一些“属性”，而这些属性，又分别具有哪些约束，在对属性进行约束完毕之后，我接口只需要一个validation，便可进行参数校验，省去了繁杂的空判断以及一些特殊属性的校验。

在Service层，我们会处理许多复杂的逻辑，但最终的目的，是将处理好的持久化。如果将持久层的东西拿出来进行各类复杂的处理之后，就算是老程序员，也很容易将需要持久化的对象，进行错误返回，所以使用Dto对象，只需要把处理完的Dto进行copyBean即可无伤转换为持久化对象（Bo）。

三、Po（Persistent Object）

Po设计的意义就是让对象只做一件事，是用于Java后端与数据库之间进行交互，Po的命名不限制于XxxxPo，而应当与数据库表和字段所对应。与前端的交互只管交给Vo去做，数据处理层的交互只管交给Dto去做，与数据库的交互只管交给Po去做。MVC架构，每层的对象分工明确。

有人说Java是一门面向对象的语言，重要的就是“对象”，而使用Vo，Dto，Po的人，反而是丢弃了面向对象的一面大旗，因为他们搞不懂自己面向的对象到底是什么，所以一概成为Vo，Dto，Po。我想说，并不是这样。Vo的命名规则，应当是前端获取的资源+Vo构成。Dto的命名规则，应当是接口名称+Dto构成。而Po的命名规则，应当与数据库相对应。对于接口Vo而言不仅明确接口返回的对象是何种资源，而且满足Restful风格的Url（url表现出获取的资源是什么）。对于Dto而言，它就是专注于该接口的一个接受参数的对象。

对于这种对象的使用方式，管理起来也很简单，只需根据接口，就能够迅速的定位到自己想要的对象是什么，如果前端需要的字段多一条，那我只需要在Vo对象中加一个属性，在业务层处理好数据，set到Vo里面去。如果我在业务层的判断需要新的字段，那我只需要定位到对应的Dto对象中，添加需要的属性。如果不使用Vo，Dto，Po进行区分，我一个刚接手的新手程序员，我应该如何去判断这个对象是个什么对象呢？它是数据库对象吗？还是返回给前端展示的对象？还是说从持久层开始到视图层，我一直都使用的是同一个对象？这样的使用方式真的合适吗？如果前端所需要的新的字段，那我应当修改返回的“持久层对象”？这应当修改吗？显然不合理。

在Springboot+vue前后端分离盛行的时代，这种对象的使用和管理方式，我认为是非常值得推荐的。