一、序言
在使用MybatisPlus作为DAO层访问数据库日益普及的今天，相应数据模型的理解变得越发的重要。如何应对企业级复杂多变的场景、如何将代码书写的更为整洁，这些都是广大技术朋友需要思考的问题。
本文将从实战的角度带来基于MybatisPlus作为DAO层访问数据库的前提下，解释各种数据模型的内涵以及数据模型之间的流转问题。本文有视频版，传送门
纸上得来终觉浅，深刻理解各种概念的内涵只有通过实战编码，才能理解其概念的内涵。
二、概念
1、DO
DO称为领域模型（Domain Object），此模型中字段属性与数据库字段具有某种一一对应的联系，一个不多一个不少，目的是屏蔽数据库，透明的进行数据库编程。
上述一一对应的联系通常是指下划线转驼峰等。
DO是使用MybatisPlus最为重要的数据模型，此模型甚至不需要显示的表明便能轻易的识别。
2、PO
一般来讲，在做数据加工的过程中，单个DO的属性过多，实际上用不上那么多属性，此时需要一个模型来做中间桥接工作。PO便应运而生，也是POJO大家庭的一部分。PO可继承DO，也可以仅包含DO中部分属性。
PO能够完成数据字段属性过滤的操作。
3、BO
如果PO在处理多个DO时，情况比较复杂，那么可引入BO辅助完成上述操作。
4、VO
VO称之为视图对象（View Object），一般来说是指控制器返回给前端的最终的模型。不管是显示的指明，还是隐士的返回，从控制器返回的实体模型均可理解为VO，与实体类命名无关。
5、DTO
DTO成为数据传输模型，顾名思义，是作为传输数据使用的。DTO广泛应用于子系统与子系统之间，不直接返回给前端，DTO与VO的根本区别是VO是单向的，由控制器返回给前端即可；DTO是双向的，既要能够转化为JSON数据，还要能够解析为具体的DTO实体。
还有一种解释是DTO作为控制器接收参数的实体，着实令人费解：第一，API接口本着小而轻的原则，接口不会太复杂，因此使用普通参数或者借助DO完全能够满足大多数需求。
少数重量提交接口，特殊问题特殊处理。
如果是为了参数隐藏而在控制器接收参数使用DTO，不在讨论范围之内。
在分析实体类数据模型流转问题，一定要考虑少数情况与多数情况的问题，这也是理论与实战的本质差别。类似于DDD，将系统拆分过细，看起来架构很清楚，实则增加开发难度。
三、小结
实际开发中，概念是死的，编程是活的。引入分层模型本质上是为了使数据才加工过程中层次清晰，方便代码复用，切不可为了分层而分层，一定要有实际内涵。
