PO，BO，VO，DTO

1、为什么要用PO？

PO用来持久化的对象，无论是字段还是类型都跟数据库表一一要对应，所以就有了PO

2、为什么要用BO?

BO是用来处理业务用的实体，业务层的入参和出参都是BO，整个业务都是围绕BO来处理

a) 有些字段应该是枚举或者对象，但是View层给你的或者数据库PO层给你的可能都是基本数据类型，我们直接使用来处理业务非常非常不方便

b) 有业务处理用到的属性和方法，这些在VO里或者PO里都不恰当

3、为什么要有VO?

VO是拿给前端展示给用户的实体

a) 有一些敏感的属性不能给前端展示，涉及安全问题

4、为什么要有DTO?

当你要调用外部业务的服务的时候，比如我们JSF服务，业务提供方也面临着类似VO一样的问题，哪些属性是可以给你的，哪些是不能给你的，给你的一些属性有可能还会有更进一步的加工。

二、分层带来的好处

1、各层次之间都解耦了

比如你可以单独把你的Servce拿出去独立部署

再比如说你调用了外部提供的JSF服务，然后你用对方提供的JAR包里的实体直接处理了业务，那万一有一天对方的JAR包升级了，或者不维护了，那你的服务是不是也会面临升级维护或者直接不可用的情况。

2、对于使用者来说比较清晰、容易维护扩展

当有人调用你的接口或者服务的时候发现接口里有一大堆参数，大多数根本是用不到的，每次用都要查一次，是不是很费劲

有人维护你开发的业务的时候也面临一样的问题，比如这个属性或者方法到底是哪个地方用到的？

三、分层带来的难处

1、每个对象可能要创建多个实体，实体之间要相互进行来回转换

怎么解决这个问题：

a) 代码生成器自动生成

b) 封装基类，自动去进行转换

四、具体怎么实践？

举例：

1、前端传给我们的参数我们自动封装成了VO

2、我们在Controller里把VO转成了BO，然后调用Service里的方法

3、Service层处理业务的时候发现要调用一个外部服务，那么就组装一个DTO参数去调用外部RPC服务，最终得到的DTO的结果我们在转成我们自己的BO再参与到业务处理中

4、Service处理的结果要查询DB，那么从DAO层返回来的是一个PO，我们也是把PO先转成我们的BO在参与业务处理

5、Service层处理完业务返回了一个BO，然后在Controller里我们把他转成VO再对外提供出去

五、遵循了原则?

原则就是永远不要在我这一层使用上层的POJO，所有跟上层交互的业务POJO都要转成我这一层的POJO来跟我交互

下层不依赖上层