最近看《重构》谈到利用OO的多态来优化 if else 和 switch 分支语句,但是我发现OO语法中的多态在使用框架的JavaEE中是无法实践的。对此,我感到十分的疑惑,加之之前项目中有个“状态模式”类的模块被频繁改动的需求折磨要死,又去看了《设计模式》。《设计模式》中也是强调,使用多态和继承来实现“状态”模式。但在采用了 SSH 或 SSM 的项目中,但我从来没有在 实体类(POJO/Bean)中见到过“继承”的语法形式。
 
于是,我搜集了所谓 POJO 、JavaBean、VO、PO、DTO这几个相近概念的含义。
 

 
POJO
 
 一:什么是POJO
POJO的名称有多种,pure old java object 、plain ordinary java object 等。
按照Martin Fowler的解释是“Plain Old Java Object”,从字面上翻译为“纯洁老式的java对象”,但大家都使用“简单java对象”来称呼它。
POJO的内在含义是指那些没有从任何类继承、也没有实现任何接口,更没有被其它框架侵入的java对象。

二:为什么会有POJO?
主要是Java的开发者被EJB的繁杂搞怕了,大家经过反思,又回归“纯洁老式”的JavaBean,即有无参构造函数,每个字段都有getter和setter的java类。

三:POJO的意义
POJO让开发者可专注于业务逻辑和脱离框架的单元测试。除此之外, 由于POJO并不须要继承框架的类或实现其接口,开发者能够极其灵活地搭建继承结构和建造应用。
POJO的意义就在于它的简单而灵活性,因为它的简单和灵活,使得POJO能够任意扩展,从而胜任多个场合,也就让一个模型贯穿多个层成为现实。
先写一个核心POJO,然后实现业务逻辑接口和持久化接口,就成了Domain Model; UI需要使用时,就实现数据绑定接口,变成VO(View Object)。

四:POJO与PO、VO的区别
POJO是指简单java对象(Plain Old Java Objects、pure old java object 或者 plain ordinary java object)。
PO是指持久对象(persistant object持久对象)。
VO是指值对象或者View对象(Value Object、View Object)。注意,本文的VO特指View Object。
持久对象实际上必须对应数据库中的entity,所以和POJO有所区别。比如说POJO是由new创建,由GC回收。但是持久对象是insert数据库创建,由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库Connection之中,Connnection关闭以后,持久对象就不存在了,而POJO只要不被GC回收,总是存在的。
由于存在诸多差别,因此持久对象PO(Persistent Object)在代码上肯定和POJO不同,起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要PO在使用上尽量和POJO一致,对于程序员来说,他们可以把PO当做POJO来用,而感觉不到PO的存在。

五:POJO的扩展
POJO仅包含最简单的字段属性,没有多余的东西,它本质上就是一个普通的JavaBean。
但是在POJO的基础上,能够扩展出不同的对象。
为POJO增加了持久化的方法(Insert、Update、Delete……)之后,POJO就变成了PO。
为POJO增加了数据绑定功能之后,POJO就变成了View Object,即UI Model。
为POJO增加业务逻辑的方法(比如单据审核、转帐……)之后,POJO就变成了Domain Model。
POJO还可以当作DTO使用。


我一直认为:概念,名词,理论无非是人用来理解、抽象事物的,是拿来用的。如果没有相应的名词,我们自己也可以创造。

个人感觉,在SSM或SSH的 JavaWeb 项目中,领域模型【Domain Model】(如成绩管理系统里面的学生、成绩等实体) 一般是被简化为 POJO ,然后这个 POJO 既用作 VO 也用作 PO 。Struts 或 Sprint MVC 用 VO 来包裹页面的数据,传给 Action  或 Controller ; Action  或 Controller 内部 用 DTO【Data Transfer Object 】互相传输数据; Hibernate 或者 MyBatis 用 PO 来包裹 业务逻辑处理过的数据 放到 数据库中。在这里,VO 和 PO 因为简单,就使用同一个 POJO 了事。但是如果我们遇到复杂的 领域模型,这个需要使用 继承和多态的 结构应该放在哪里呢 ?  POJO ? PO?VO?DTO?我觉得,这时候,是不是就应该需要另外一层 ?

举个在《设计模式:Java语言》中的“状态模式”的例子。

书中建议使用 状态模式,也就是说需要 设计 含有继承关系的几个类。如果这个功能出现在采用了 SSM 框架的 JavaEE项目中,那么,这个继承关系该设计到哪里呢?

05-26 10:10