java项目架构_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)。

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

举个简单的J2EE的例子，设计一个与用户(User)相关的功能：

传统的设计一般是：类：User+UserManager保存用户调用：userManager.save(User user);

充血的设计则可能会是：类：User保存用户调用：user.save(); User有一个行为是：保存它自己总结：

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

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

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