vo、dto、bo、do、po的概念理解以及与controller、service、dao层的对应关系

---

概念

• VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。
• DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，更符合泛指用于展示层与服务层之间的数据传输对象。
• BO（Business Object）：业务对象，把业务逻辑封装为一个对象，这个对象可以包括一个或多个其它的对象。
• PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。
• DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

关于do的理解

do和po很难理解，这个地方举个例子，比如我有一个po存储了某种商品的价格原始信息，但是当我的service中要读取商品的价格信息的时候，除了需要这些原始信息，还需要根据折扣再要基准折扣价之类的信息，而这类信息是要通过数据库中已有信息计算得到的。
简而言之，service在读取po的时候，需要在po外增补一些冗余数据、而这些数据，通常不会保存在数据库中，但又是多个service共用的。这类数据

1. 放在service中new一个自定义对象不合适，因为其他service中也经常要用，这样无法做到service间代码的复用
2. 直接用po也不合适，因为po是直接操作数据库对象的，数据库中也没有这个冗余字段。

所以此时最好是在serveice层和dao层之间，再抽象出一个o，其中不只存放了po的基础信息，还存储了一些基于po的冗余计算属性，或者对po做一些魔改。
但是现在由于使用的jpa或mybatis框架，是支持标明entity中哪些属性是db的原始属性，哪些属性不是db中的属性的，实际上做的事情就是将do和po做了整合，以后可以认为不需要单独再搞一个do对象进行数据操作了。

业务逻辑分层

M层负责与数据库打交道；

C层负责业务逻辑的编写；

V层负责给用户展示（针对于前后端不分离的项目，不分离项目那种编写模版的方式，理解V的概念更直观）。

基于springboot的逻辑分层结构

以上逻辑分层翻译成常见的springboot结构就是

什么时候需要定义这么多O

项目中真的有必要定义VO，BO，PO，DO，DTO吗？按照理论上来讲

• 如果项目比较小，是一个简单的MVC项目，又是单兵作战，我不建议使用VO，BO，PO，DO，DTO，直接用POJO负责各个层来传输就好，因为这种项目的“目的地”是快速完成。
• 而我们更多的时候，是持续迭代的团队协作项目，这个时候我们就建议用VO，BO，PO，DO，DTO，而且团队内要达成共识，形成一个标准规范。

目的是提升项目的可扩展性、可维护性与可阅读性。

其实要不要用这么多o，关键问题在于关注controller、service、dao这些层间数据有没有变化。比如vo传进来，放进service直接拆成po，那就没有dto什么事。如果存在rpc调用，就需要考虑一下，要不要新加一个object。对象数量的选择，完全根据层间数据变化来决定

实际项目中的使用方式

同一微服务中

一般controller向service传的数据和service向controller传的数据不一定相同，这就导致每层的dto、po等对象都可能有两个

不同微服务

因为不同微服务中涉及到RPC远程调用，所以经常会有重复的object对象出现在不通服务中。

一般起名规则

名称中，要写明对象涉及的两层逻辑，最好再写明数据流向。