POJO式开发

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 在一定程度上就是鼓励人们编写过程式代码，