vo、dto、bo、do、po的概念理解以及与controller、service、dao层的对应关系
项目中真的有必要定义吗?按照理论上来讲如果项目比较小,是一个简单的MVC项目,又是单兵作战,我不建议使用,直接用POJO负责各个层来传输就好,因为这种项目的“目的地”是快速完成。而我们更多的时候,是持续迭代的团队协作项目,这个时候我们就建议用,而且团队内要达成共识,形成一个标准规范。目的是提升项目的可扩展性、可维护性与可阅读性。其实要不要用这么多o,关键问题在于关注controller、servi
概念
- 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共用的。这类数据
- 放在service中new一个自定义对象不合适,因为其他service中也经常要用,这样无法做到service间代码的复用
- 直接用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对象出现在不通服务中。
一般起名规则
名称中,要写明对象涉及的两层逻辑,最好再写明数据流向。
更多推荐
所有评论(0)