复杂的软件系统都会采用分层的架构设计,分层之后,每一层职责鲜明,整体上降低了系统的耦合性,提高了健壮性。
Java 服务端开发亦是如此,采用分层架构,针对每一层,对应对象的职责是不同的,以及层与层之间也需要通信,故而有着不同的“概念”对象。
分层领域模型规约:
领域模型命名规约:
理解 PO 和 VO 需要先理解 ORM,ORM(Object Relational Mapping 对象关系映射)就是将对象与关系数据库绑定,用对象来表示关系数据。映射需要 Hibernate 和 MyBatis 等框架执行,操作过程中,根据不同的 ORM Framework 编写不同的映射文件,一般是以 xml 方式进行存储,将表与 Javabean 的值对象一一对应。
以前插入一条记录书写形式为:
现在可以如下书写:
这么做最基本的好处就是:关系发生改变直接改动映射配置文件即可,不需要到源文件里面去一条条修改语句(主要是 sql 语句)。
在 O/R 映射的世界里,PO(Persisent Object 持久对象)和 VO(Value Object 值对象)是两个基本的概念。PO 与 VO 均由一组属性和属性的 get 和 set 方法组成,结构上没有不同,但是本质上完全不同。
PO 通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的 java 对象。最简单的 PO 就是对应数据库中某个表中的一条记录,多个记录可以用 PO 的集合。PO 中应该不包含任何对数据库的操作。
VO 通常用于业务层之间的数据传递,和 PO 一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要。
区别点:
如果没有 PO 和 VO 的区别,那么数据库表结构的所有字段就一览无余地展示到了前端,给后台安全带来很大的隐患,并且无法在网络传输中剥离冗余信息提高了用户的带宽成本。
DTO(Data Transfer Object 数据传输对象) 指用于展示层与服务层之间的数据传输对象。主要用于远程调用等需要大量传输对象的地方。比如一张表有 100 个字段,那么对应的 PO 就有 100 个属性。但是界面上只要显示 10 个字段,客户端用 WEB service 来获取数据,没有必要把整个 PO 对象传递到客户端,这时就可以用只有这 10 个属性的 DTO 来传递结果到客户端,这样也不会暴露服务端表结构.到达客户端以后,如果用这个对象来对应界面显示,那此时它的身份就转为 VO。
**DAO(Data Access Object 数据访问对象)**是 sun 的一个标准 j2ee 设计模式,这个模式中有个接口就是 DAO,它负持久层的操作。为业务层提供接口。此对象用于访问数据库。通常和 PO 结合使用,DAO 中包含了各种数据库的操作方法。通过它的方法,结合 PO 对数据库进行相关的操作。夹在业务逻辑与数据库资源中间。配合 VO,提供数据库的 CRUD 操作,应当注意 DAO 中应该只关心数据库的 CRUD 操作,而不应掺杂业务逻辑。
**BO(Business Object 业务对象)**封装业务逻辑的 java 对象,通过调用 DAO 方法,结合 PO,VO 进行业务操作。主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。比如一个简历,有教育经历、工作经历、社会关系等等。可以把教育经历对应一个 PO,工作经历对应一个 PO,社会关系对应一个 PO。建立一个对应简历的 BO 对象处理简历,每个 BO 包含这些 PO。这样处理业务逻辑时,我们就可以针对 BO 去处理。
**POJO(Plain Ordinary Java Object)**简单无规则 java 对象,纯的传统意义的 java 对象。就是说在一些 Object/Relation Mapping 工具中,能够做到维护数据库表记录的 persisent object 完全是一个符合 Java Bean 规范的纯 Java 对象,没有增加别的属性和方法。就是最基本的 Java Bean,只有属性字段及 setter 和 getter 方法。