Java 常见名词解释

POJO

简单的 Java 对象（Plain ordinary Java Objects）实际就是普通 JavaBeans,使用 POJO 名称是为了避免和 EJB 混淆起来, 而且简称比较直接。

其中有一些属性及其 getter setter 方法的类,有时可以作为 value object 或 dto(Data Transform Object)来使用。

当然,如果你有一个简单的运算属性也是可以的,但不允许有业务方法,也不能携带有 connection 之类的方法。

PO

PO(persistant object) 持久对象，可以看成是与数据库中的表相映射的 java 对象。一张表对映一个 PO。

最简单的 PO 就是对应数据库中某个表中的一条记录，多个记录可以用 PO 的集合。PO 中应该不包含任何对数据库的操作。

DAO

DAO (data access object) 数据访问对象，此对象用于访问数据库。

通常和 PO 结合使用，DAO 中包含了各种数据库的操作方法。通过它的方法,结合 PO 对数据库进行相关的操作。

DTO

DTO (Data Transfer Object)

数据传输对象,主要用于远程调用等需要大量传输对象的地方。比如我们一张表有 100 个字段，那么对应的 PO 就有 100 个属性,但是我们界面上只要显示 10 个字段，客户端用 WEB service 来获取数据，没有必要把整个 PO 对象传递到客户端，这时我们就可以用只有这 10 个属性的 DTO 来传递结果到客户端，这样也不会暴露服务端表结构。到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为 VO。

VO

VO(value object) 值对象，通常用于业务层之间的数据传递，和 PO 一样也是仅仅包含数据而已。

但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要。个人觉得同 DTO(数据传输对象),在 web 上传递。

BO

BO：全称是 business object:业务对象，主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。

比如一个简历，有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个 PO，工作经历对应一个 PO，社会关系对应一个 PO。

建立一个对应简历的 BO 对象处理简历，每个 BO 包含这些 PO。这样处理业务逻辑时，我们就可以针对 BO 去处理。

biz

biz 是 Business 的缩写，是业务逻辑层，一般意义上和 service 层差不多。项目前期或者小项目没什么太大区别，但是项目大了以后区别就很大了。

项目开发到后期的话，一个项目内包含有其他的小项目，比如：后台、erp、商城等等，都用的是同一个数据库。这个时候，就不能使用一个 service/biz 全部解决了。有些业务是通用的，有一些业务可能只有 erp 有，其他模块没有，也有可能同一个业务，在细微上有一些差别，如果全部都放进一个业务层中的话，这个业务层就会非常的臃肿。这个时候就需要拆分，一个基础业务层，一个应用层业务层，基础业务层只是针对该对象的 CURD 操作

应用业务层就是一个复杂的功能模块或流程。

这时可以考虑 service 作基础业务层，biz 作为应用层业务层。service 是比较底层的 api，biz 是应用层的 api。可以结合 DDD 领域驱动设计理解。

充血模型与贫血模型

贫血模型最早广泛应用是源自于 EJB2，最强盛时期则是由 Spring 创造，把“行为”（也称为逻辑、过程）和“状态”（可理解为数据，对应到语言就是对象成员变量）分离到不同的对象之中，那个只有状态的对象就是所谓的“贫血对象”（常称为 VO——Value Object），而那个只有行为的对象就是我们常见的 N 层结构中的 Logic/Service/Manager 层（对应到 EJB2 中的 Stateless Session Bean）。

充血模型其实很简单，就是面向对象设计的本质：“一个对象是拥有状态和行为的”，比如说一个人，他眼睛什么样鼻子什么样这就是状态，人可以去打游戏或是写程序，这就是行为。

总结

贫血模型, 将数据与 db 操作分离, 分个好几层, 如 entity/dao/service 等。

充血模型, 数据与 db 操作绑在一次, 一般只涉及到一两层。

充血模型层数少,代码少, 改动少, 简单, 优雅，一般复杂的系统可以考虑用充血模型，简单系统用贫血模型也并没有什么影响。

如若转载，请注明出处：开源字节   https://sourcebyte.cn/article/229.html