为什么会出现这些O？

我们知道，这些O不管叫什么名字，其本质都还是对象（Object），既然本质都一样，为什么非要给他们套上各种马甲？

大神认为原因有三：

  • 第一，随着编程工业化的发展，需要有一套合理的体系出现。中国人喜欢造神，外国人喜欢造概念，于是 MVC、MVP、MVVM 等编程模型就出现了，为了搭配这些编程模型的使用，需要对 Object 的功能进行划分，于是我们便看到了这些层出不穷的 Object。当然这里并没有批评这些概念的意思。
  • 其二，我认为在团队协作编码中，一个好的命名方式是可以节约很多时间成本的。就比如getItemById一眼看去就知道是通过 id 获取一个 item 对象，ItemVO一眼看去就知道是前端透出的 json 对应的对象。
  • 其三，如此划分，可以让项目结构更加清楚，不至于出现东一块西一块，对象乱扔的局面。尽可能避免了在多人协作时对象混乱的情况。总的来说，这一切都是为了让软件编程更加合理、更加规范、更加高效。

有哪些O？

这些O有很多衍生出的命名，比如VO、DO、BO，这里我们把常见的O列举出来，然后一一解释。

  • DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
  • PO（Persistant Object）：持久对象，一个 PO 的数据结构对应着库中表的结构，表中的一条记录就是一个PO对象
  • DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
  • BO（ Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。
  • AO（ Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
  • VO（ View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。
  • POJO（ Plain Ordinary Java Object）：POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO 等。
  • DAO（Data Access Objects）：数据访问对象，和上面那些O不同的是，其功能是用于进行数据操作的。通常不会用于描述数据实体。

参考：阿里巴巴 Java 开发手册

数据的流向

image-20200814162221877

我们知道，一般情况下，前端是不会凭空造出数据的，因此最后前端展示的数据一定是从数据库中来的，数据的流向通常也是从数据库流向页面。我将其分成三个部分：数据访问、业务处理和业务解释。

  1. 数据访问：这一部分是用于从数据库中读取数据，将数据记录转换成数据实体也就是Java对象，便于操作。
  2. 业务处理：这一部分是数据流的核心，几乎所有数据的操作都是在这一部分完成的。
  3. 业务解释：这一部分是用于展示给前端的数据，解释业务体现在某些字段/值是需要经过处理的才会呈现的。

关键点

  • DAO，是用于操作数据而不是描述数据的。
  • PO/DO/Entity，其数据结构对应数据表中的一条记录，因此是同一类别的。
  • BO，可以理解为PO的组合，举个简单的例子，假设PO是一条交易记录，BO就可以是一个人全部的交易记录集合对象。
  • DTO，用于传输数据，可能传递给前端，也有可能传递给其他系统。用于承载数据。
  • VO，这个最好理解，前端最后需要的数据长什么样，对应的对象就是VO。

如何使用这些O？

教条主义？

首先，这几个概念很完整，但是我们在用的时候是必须按这个来做吗？答案当然不是的，规矩是死的，人是活的。文章开头我们就说了，之所以引入这些概念，很大程度上是为了提升编程体验，而且系统和系统的复杂度不同，协作水平不同，完全没有必要教条主义，适合自己的才是最好的

省略方案

  1. 不管你是叫PO还是DO还是Entity，用于描述数据库记录的对象一定要存在，不可省略。
  2. DTO和BO在一般情况下，如果业务系统不是非常复杂，可以考虑省略。
  3. VO和DTO，DTO可以用于将数据传递给前端，如果你不需要删减字段的话，VO可以考虑省略。

注意事项

领域模型命名规约：

  • 数据对象：xxxDO，xxx 即为数据表名。
  • 数据传输对象：xxxDTO，xxx 为业务领域相关的名称。
  • 展示对象：xxxVO，xxx 一般为网页名称。
  • POJO是DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。

文章来源，微信公众号：Java3y