在项目中不同层次之间，为了降低耦合性，便于维护和拓展，通常使用不同的模型。
DTO (Data Transger Object) 为数据传输对象，通常将底层的数据聚合传给外部系统，它通常用作 Service 和 Manager 层向上层返回的对象。如果作为分布式服务的参数或返回对象，通常要实现序列化接口。
**BO (Bussiness Object) **即业务对象。该对象中通常包含业务逻辑。比如 BO 中可以保存中间状态，放一些逻辑等，这些并不适合放在 DTO
VO (View Object) 为视图对象，通常作为控制层通过 JSON 返回给前端然后前端渲染或者加载页面模板在后端进行填充。
**AO (Application Object) **应用对象。通常用在控制层和服务层之间。有些团队会将前端查询的属性和保存的属性几乎一致的对象封装为 AO，如读取用户属性传给前端，用户在前端编辑了用户属性后传回后端。这种用法将 AO 用作 Param 和 VO 或 Param 和 DTO 的组合。
在实习的时候，项目中采用的是控制层直接返回DTO对象给前端，而服务层和持久层都是返回entities对象或者响应的集合类。可能在大型项目中为了更加职责清晰，会分的更加清晰。
另外在做的 项目中也有返回VO对象的，针对不同的业务场景返回不同的VO类型，同时为了降低查询时合并查询的复杂度，设计一个合并的VO的对象。从数据表设计的角度看会产生一些冗余，但是能够把需要用的数据保存在一张表中。
不同类型之间转换的一些工具：
1、直接采用getter/setter方法来进行转化，这种方式快速，能够根据需要进行调整，对于对象比较简单的情况比较适合；
2、采用 commons 和 Spring 的 BeanUtil，本质上是采用了反射机制，效率比较低。
3、另外有一些工具orika，mapStruct等，采用基于字节码技术的方式进行修改，速度比较快，但是需要注意，当属性修改时工具类可能不会报错从而产生一些意外的Bug
