java和三层_Java为什么有三层设计和VO、DTO、PO等对象？

为什么有三层设计：

一个项目的工作流程可以概括成：数据库读出数据→处理数据→把数据给前端(显示数据)，接收数据→处理数据→写入数据库。比如我打开这个问题，那么知乎服务器就是从数据库读出这个问题相关的记录，处理一下，返回给前端，最后显示到页面上。而三层架构实际上就是把这三个步骤划分清楚，用接口相互连接，从而可以分别处理。

实际上，三层架构更应该说是根据不同的操作来划分。上面的工作流程实际上有三种不同类型的操作，一是对数据库的操作，二是对数据的处理，三是与前端交互的操作，三层架构本质上就是把这三种不同的操作划分开来：对数据库的操作，增删改查——数据访问层

对数据的处理，加减乘除比大小这种——业务逻辑层

与前端交互的操作，接受用户请求，返回数据——表示层

下面举一个例子，比如现在我们要实现一个知乎用户登录功能的简化版，需要接收用户填的用户名、密码，然后比对数据库里的记录，最后返回一个登陆成功或者登录失败。那么用三层架构怎么设计呢？

首先用户填好的信息被发到了服务器，得有个东西来接收，这个东西就是表示层。表示层接收到了用户名和密码会处理吗？不会，因为这不是表示层的工作，表示层只是调用一个登录方法并把参数传进去。那这个登陆方法应该是谁来实现呢？业务逻辑层，登录显然是一个具体的业务。

业务逻辑层实现的登录方法需要比对数据库里的记录来确认密码是否正确，那么业务逻辑层会访问数据库吗？不会，这是数据访问层的工作。业务逻辑层也只是调用一个方法，而这个方法会由数据访问层实现。

数据访问层返回了记录的密码，业务逻辑层比对之后发现密码是正确的，就返回给表示层，表示层这时候就给用户返回一个登陆成功，这个功能就完成了。总结一下：

可以看到，通过三层架构设计，不同作用的代码得以在不同层级上完成。不同层级之间通过接口联系，使得每一层只需要关心自己接口的实现，同时只要实现了接口，就可以随意改动而不用担心影响到其他层级的代码。

其实对于小项目来说，把这三个层次混在一起也不是不可以，但是对于较大的项目，三级架构有非常大的益处，上面这个例子只是用户登录的简化版，而知乎拥有的功能要多得多得多，如果各种代码混在一起那就没法看了，分层设计会让整个项目变得非常清晰。

比如要加一个访问个人主页的功能，只需要在表示层加一个接收请求的函数，调用一个业务逻辑层实现的方法就可以解决了，数据访问层不需要改动，因为跟登录一样都是从数据库里面读出这个用户的这一条记录。再比如如果现在数据库里面有一列的数据类型发生了变化，那么在三级架构中只需要在数据访问层做一下类型转换就可以了，其他代码完全不受影响，但如果是没有分层的设计，那就得把每一个方法里涉及数据库的部分都改一遍，这个工作量显然是巨大的。

VO，DTO，PO是啥：

PO：这个最简单，就是数据库读出来的数据对象。按照刚才的例子，PO就是数据访问层返回的包含用户信息的对象。为什么要有一个对象？因为这是JAVA，数据库里面一条记录可能包含用户名、性别、注册时间、头像等等信息，有一个对象来存显然是最合理的选择。

DTO：有了PO为什么不直接用PO进行处理？因为PO不一定好用。以用户登录为例，在数据库设计时，为了安全，用户信息和密码要分表设计，也就是说密码表是单独的，靠用户id来关联到用户信息里。如果现在我们要在登录之后直接进入用户主页，就需要头像、性别这些信息，那么在查询的时候需要两个表分别查一次，用户名或者手机号查用户信息表获得用户信息，查密码表获得密码。这样的话，数据访问层实际上是要返回两个对象，一个里面是除了密码以外的信息，另一个对象包含密码。但是我们在操作过程中希望用户所有的信息都在一个对象里，要不每次都要处理俩对象太麻烦了，所以就新设计一个DTO，返回出两个对象之后调用一个方法，把所有用户相关的信息都写到一个DTO里面，这样之后业务逻辑层无论想干啥只需要处理这一个对象就可以了。

有人可能会问，密码这东西又不会显示在个人主页上，为啥要做进去？那再举个例子，一个电商平台的商品信息和库存往往是分开的，因为库存时刻都会发生变化，每次更改都要访问一个包含商品介绍、图片等等信息的表太慢了，所以都是单独有一个库存表来加快访问速度。但是业务逻辑层处理商品详情的时候难道可以不包含库存吗？所以需要有一个DTO把商品信息和库存都做进去，方便处理。

VO：返回前端的对象。为什么不直接返回DTO？因为不一定DTO里面所有的信息都要给前端。用户信息的DTO里可能有密码、登陆所在ip等等不希望用户看到的信息，所以表示层在给前端返回数据的时候可以创造一个专门的VO来存希望给用户看的信息。

总结一下，PO是数据访问层搞出来的，DTO是业务逻辑层拿来用的，VO是表示层用来返回给用户看的。