POJO
POJO就是简单java对象,不实现任何特殊接口。POJO这一名字由Fower、Rebbecca、Parsos、Josh MacKenzie(Foeler POJO)发明,目的地是为了给普通Java对象取个令人兴奋的、过目不忘的名字。
早期EJB及其存在的问题
EJB1.0版本发布于1998年,它提供了两种企业bean:会话bean和试题bean。会话bean便是无状态服务或与客户端之间的有状态会话。实体bean表示数据库里的数据,最初意在实现业务对象。EHB2提炼了EJB编程模型。不仅增加了支持由容器管理的关系增强型实体bean,还新增了消息驱动bean(负责处理Java Message Service或JMS,消息)。
EJB存在的问题
尽管有很多书帮助开发人员对付EJB,并学会如何有效的使用EJB,但是EJB的;两个主要问题并没有直接解决。
第一, EJB鼓励开发人员编写过程式应用程序
第二, 使用EJB开发相当麻烦
过程式设计的缺点:
对业务逻辑的组织方式主要有两种:过程式或面向对象。过程式方式以函数为单元组织代码,这些函数操作单独的简单数据对象。在过程式架构中,数据结构遍布各处,并作为参数传入函数,或返回给调用函数。数据与操作之间的关系非常松散,并且完全由开发人员自己维护。在面向对象语言出现之前,这种编程方式主导了软件开发。
与之相比,面向对象方法则以对象为单元组织代码,这些对象具有状态和行为,并与其他对象协作。数据结构和操作定义在一个语言构造单元内,数据和对数据操作并存于其中。数据和操作之间的关系(和状态)由语言本省维护。与过程式设计相比,面向对象设计更易理解、维护、扩展和测试。
如果业务逻辑够简单,过程式设计方法倒也不成问题,但是业务逻辑总有变得愈加复杂的趋势。一旦需求改变,业务逻辑就必须实现新的特性,EJB的代码量会不断增加。
EJB2在一定程度上就是鼓励人们编写过程式代码,实现新行为时,不必像设计真正的对象模型那样费心地识别类并赋予其职责。相反,你可以编写一个新的会话bean方法或在现有方法里添加代码。
这钟过程式的设计方法,有些开发人员仍把持久对象简单的视为一种向数据库存取数据和编写过程式业务逻辑方法,这就是所谓的贫血模型
EJB开发的麻烦:
n 你必须面对恼人而长的编辑-编译-调试周期
n 你得面对关注点缺少分离的显示
n 你必须编写大量的代码才能实现一个EJB
n 你必须编写数据传输对象(DTO)
用POJO开发
用POJO进行开发,仅有POJO本身还是不够的。在企业应用程序里,你还需要诸如事务管理、安全和持久化等服务,此前这些服务由EJB容器提供。现在的解决方案是使用所谓“轻量级”框架来代替J2EE STACK里的一些“重量级”部分。主要是4种轻量级框架:Hibernate、JDO、Ibatis和Spring。
这些技术的主要特征在于他们都是非侵入式的。它们提供事务和持久化时并不要求应用程序类实现任何特殊接口。甚至当应用程序的类需要运行在事务里或者持久化的时候,它们仍是POJO。
典型的EJB和POJO方法比较
|
典型的EJB方法 |
POJO方法 |
组织 |
过程式业务逻辑 |
面向对象设计 |
实现 |
基于EJB |
POJO |
数据库访问 |
JDBC/SQL或实体Bean |
持久层框架 |
返回给表示层的数据 |
DTO |
业务对象 |
事务管理 |
EJB容器管理的事务 |
Spring框架 |
应用程序组装 |
显示的JNDI查询 |
依赖注入 |
l 面向对象设计
整个设计更容易理解和维护
更易于测试
更易扩展
l 使用POJO
开发更加容易
更加快捷
可移植性增强
l 持久化POJO
使用JDO和Hibernate提供透明持久化,这意味着类不会意识到它们是持久的。应用程序只需要调用持久层框架API保存、查询和删除持久对象、而且对测试也很方便。
l 消除DTO
DTO又称为值对象(value object)。DTO只是一个由成员变量组成的简单行为对象,用于从业务层向表示层返回数据。这是由于表示层无法高效地访问EJB2实体bean,因此EJB程序需要DTO。
向表示层返回Hibernate、JDO、EJB3对象有两种方式。一种选择是表示层返回仍持久地的对象。另一种做法是让业务层返回脱管对象。
l 是POJO具有事务性
用spring管理事务。对测试也很方便。