概念不清,会很影响开发中的逻辑性和条理性,进而影响接口设计,代码编写的质量。
网络上大家对这些个概念的探究很多,但终究没有一个统一的说法。
不论哪家解释,我觉得最重要的是: 1)词汇之间的解释统一; 2)词汇之间的联系不冲突,能自圆其说,自成一体。
在自己初步探索后,个人更认同这样的理念(如下)。
若读者凑巧阅读到本文,欢迎一起探讨。
1 POJO := Plain Ordinary Java Object
POJO := Plain Ordinary Java Object
简单的Java对象
POJO ⊇ { PO, DTO, VO }
PO := Persistent Object
持久对象
用途: 用于表示数据库中的一条记录,映射成Java对象
PO仅用于表示数据库数据,无任何其它的数据操作
DTO := Data Transfer Object
数据传输对象
用途: DTO通常用于【不同Web服务之间(RestFul / RPC调用 / WebService调用等)】或【同一服务的不同分层之间的数据传输】 ; 减小数据传输量
一个DTO可以对应多个从存储层返回的PO(Persistent Object)的json数组,这里可以使用AutoMapper来进行自适配。
- DTO存在的必要性
DTO不是为MVC的视图而存在的模型,而是为了适应来自前端请求而存在的。
DTO模型把来自前端的请求(这个请求不管来自前后端分离的页面,还是mvc的视图页面)封装在DTO模型中,然后服务端处理转换成Entity Framework中的PO模型。
VO := View Object(个人更认同) := Value Object
视图对象/值对象
VO for request and response of users or controller layers
用途: 用于表示一个与前端交互的Java对象;用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。
举例:展示层将DTO传送过来男性显示成帅哥(客户端1),或者显示成靓仔(客户端2);将帅哥或者靓仔,转换成男性,以DTO形式请求服务端。
视图模型VO可以对应客户端的网页显示,同样的DTO比如性别男,可以对应多个VO进行显示,即可以对应多个客户端,比如VO1把性别男显示成帅哥,VO2把性别男显示成靓仔等等。
- 视图对象存在的必要性/ VO VS DTO
如果是一个DTO对应一个VO,则DTO=VO;
但是如果一个DTO对应多个VO,则展示层需要把VO转换为服务层对应方法所要求的DTO,传送给服务层。
从而达到服务层与展示层解耦的效果。
- VO VS PO:
PO: 纯数据库表记录的完全映射;
VO: 仅包含前端需要展示的数据/属性;(需要对前端/用户屏蔽部分字段;减小数据传输量)
2 BO/DO := Business Object / Domain Object
BO/DO := Business Object / Domain Object
业务对象/领域对象
BO 包含了业务逻辑,常封装了对DAO,RPC等的调用;
可进行PO,VO,DTO之间的转换;
通常属于业务层,但要区别于直接对外提供服务的服务层;
BO提供基本业务单元的基本业务操作,在设计上属于被服务层业务流程调用的对象,一个业务流程可能需要调用多个BO来完成
3 DAO
Database Access Object
数据库访问对象
用途: 用DAO访问数据库,包括增删查改等操作;同POJO一起使用
4 小结
来源网络,并非权威,仅供参考
假定: 我们有一个面试系统,数据库中存储了很多面试题,通过 web 和 API 提供服务。可能会做如下的设计:
- 数据库表:面试题{编号(ID)、题目(Question)、选项(OPTIONS)、答案(ANSWER)、创建时间(CREATE_TIME)、修改时间(UPDATE_TIME)}
- PO:{ 题目、选项、答案、创建时间、修改时间 }
- VO:{ 题目、选项、答案、上一题URL、下一题URL }
- DTO:{ 编号、题目、选项、答案、上一题编号、下一题编号 }
- DAO:{ methods增、methods删、methods改、methods查 }
- BO:{ #业务基本操作# }