实战讲解MybatisPlus DO PO BO DTO VO 数据模型及其流转 附视频

一、序言

在使用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，将系统拆分过细，看起来架构很清楚，实则增加开发难度。

三、小结

实际开发中，概念是死的，编程是活的。引入分层模型本质上是为了使数据才加工过程中层次清晰，方便代码复用，切不可为了分层而分层，一定要有实际内涵。