航天大学计算机学院的教学

《航天大学计算机学院的教学》由会员分享，可在线阅读，更多相关《航天大学计算机学院的教学（43页珍藏版）》请在金锄头文库上搜索。

1、声明 本课件仅用于北京航空航天大学计算机学 院的教学； 本课件修改采用了一些网络资源（论文、 研究报告、技术报告等），在采用的时候 并没有准确标注引用信息。有关J2EE的流言 1.关系-对象映射 2.EJB的简化 3.轻量级框架和容器1. 对象-关系映射 对象-关系映射 （Object/Relation Mapping，简称ORM） 面向对象的开发方法是当今企业级应用开发 环境中的主流开发方法 关系数据库是 企业级应用环境中永久存放数 据的主流数据存储系统 对象和关系数据是业务实体的两种表现形式 业务实体在内存中表现为对象 在数据库中表现为关系数据 数据持久化（对象-关系映射）方法： Enti

2、ty Bean 会话 bean 和 JDBC JDO(Java Data Object) Hibernate iBatis , TopLink, Entity Bean 实体Bean作为企业数据持久性机制具有 如下优点： 标准化 透明的持久性 事务支持 基于组件的设计 容器管理的服务。EJB 容器使开发人员不必 管理常见的企业功能，如安全性、事务处理 、连接合用和外部资源管理。 实体 bean 的主要缺点： 设计复杂性。容器管理的服务和自动且透明的持久性 为整个应用程序设计引入了复杂性。实体 bean 通常 也可以通过会话 bean 来访问，这意味着每个事务至 少包含两个企业 bean，而通常

3、会更多。 构建周期很长。一个 EJB 周期（设计构建测试 集成测试部署）所花的时间比可比的 Java 持 久性解决方案多两到三倍。 响应时间。实体 bean 与 bean 实例的粒度相关。因 此，开发人员始终面临选择：要么将 bean 按原样装 入，而在别的方面解决响应时间长的问题；要么将数 据分解成较小的实体，从而创建更复杂的系统体系结 构。 资源使用情况。实体 bean 消耗了大量系统资源。会话 bean 和 JDBC 会话 bean 和 JDBC 组合最受认可的优点如下： 设计简单。从体系结构设计观点来看，通过会话 bean 来直接处 理数据管理比使用实体 bean 简单得多。 细粒度的

4、控制。因为会话 bean 是通用的工作程序组件，所以它 们允许开发人员完全控制整个持久性过程，包括高速缓存、持 久性、并发性、同步及其它。相反，CMP 实体 bean 不允许开 发人员控制持久性机制，而 BMP 实体 bean 仅使开发人员能够 定义应发生什么，而不能定义应在何时或什么样的情况下发生 。 成熟。JDBC 存在了七年左右！而实体 bean 出现至今只有三年 多的时间。JDBC 的可靠性和最佳实践对于 J2EE 持久性机制 的开发来说是一笔非常宝贵的资产。 速度。因为开发人员完全控制在会话 bean 中使用的数据访问机 制，所以可以针对某些任务优化数据访问和持久性逻辑。由于 直接和

5、有目的的操作，这可以产生极快的响应时间。 缺点如下： 实现复杂。虽然这种系统的体系结构设计相当简单， 但实际的会话 bean 实现常常十分复杂。如果应用程 序的数据需求相当复杂，那么可能就无法实现管理数 据库连接、确保数据完整性以及正确处理事务语义这 些关键任务。开发人员常常需要实现某种类型的高速 缓存同时确保最优性能。构造这种高速缓存机制使该 系统的开发和维护进一步复杂化。 非固有的事务性。实体 bean 本质上是事务性组件， 这些组件具有可配置的事务语义；而会话 bean 没有 。将事务语义直接编码到应用程序代码中时，开发人 员必须处处小心以确保每个功能的业务规则、流控制 和事务完整性都得

6、以保护并且可以容错。在实体 bean 开发中，这些细节都由容器处理。 持久性不是自动的或者得不到保证。在实体 bean 操 作中，容器处理 bean 状态的持久性，并确保这种数 据得到保护，供以后使用。对于会话 bean，将数据 保持在安全、长期的数据存储中是开发人员的责任。 JDO(Java Data Object) JDO 提供了面向对象的持久数据存储。开 发人员使用 POJO（无格式普通 Java 对 象，plain ordinary Java object）来装入 和存储持久数据。 会话 bean 与 JDO 结合类似于将它们与 JDBC 结合，但 JDO 是以更面向对象且 更以 Ja

7、va 为中心的观点处理该问题的。 会话 bean 和 JDO 提供了许多优点，其中有些 来自会话 bean，而其它的来自 JDO，使用会话 bean 而不使用实体 bean 进行交付的主要优点 有两个： 设计简单。从体系结构设计的观点来看，直接通过会 话 bean 来处理数据管理比使用实体 bean 简单得多 。 细粒度控制。因为会话 bean 是通用的工作程序组件 ，所以它们允许开发人员对整个持久性进程进行完全 控制，包括高速缓存、持久性、并发性和同步等。 这两个优点并不是会话 beanJDO 组合所特有 的：会话 bean 与 JDBC 的结对也存在这两个 优点。但是，JDO 确实提供了一

8、些独特的优点 ： 编码简单。JDO 体系结构向开发人员隐藏了低级别 的持久性细节，从而使他们专注于从业务过程的角度 管理对象，不至于陷入数据持久性逻辑的琐碎细节中 。 提高的生产力。JDO 程序员能完全在面向对象的范 例内操作。这通常会使开发更简洁、更平滑且更不易 出错，因为程序员不用在关系的思想体系和面向对象 的思想体系之间频繁地转换。 面向对象的持久性。JDO 的面向对象本质不仅提高 了开发人员生产力，而且它还考虑到比关系持久性所 提供的还要丰富的持久性机制。JDO 并不仅仅使 Java 对象持久；它还透明地处理整个相关对象图的 持久性。因此，当实例被持久存储时，它所维护的对 其它对象实例

9、的任何内部引用也都被持久存储（除非 它们已被声明为瞬态）。JDO 还存储类型层次结构 的完整信息，并能根据类型（父类和接口）实现请求 ，而不是只了解持久实例的特定局部类型。 缺点： JDO 不成熟。JDO 还处于初期。到编写本文时， JDO 1.0 规范的发布还不到一年。其结果是，JDO 社区还非常小，最大且最具威望的 JDO 门户网站可 以炫耀的也只是其会员有五千多一点。尽管这些数据 并不表示 JDO 是一种差劲的技术，但它们确实表明 它还处于前沿。几乎没有几家公司愿意尝试在业务级 实现中使用 JDO。 会话 bean 不是事务性的。J2EE 客户机不能直接访 问 JDO 对象。必须由 se

10、rvlet 或会话 bean 处理进入 请求。因此，尽管很容易将 JDO 对象声明为事务性 的，但仍必须使用非事务性组件来访问它们。在将事 务语义直接编码到会话 bean 的应用程序代码中时， 开发人员必须尽一切可能确保每个功能的业务规则、 流程控制和事务完整性都得以保留并是容错的。尽管 使用容器管理的事务可以极大地缓解这一问题，但是 这样做限制了开发人员对持久性进程的控制，并除去 了许多控制事务粒度所产生的体系结构上的灵活性。 Hibernate Persistent Object是简单的业务实体对象( 要被持久化的对象)。通过hibernate被透 明的持久化到数据库中。 表person

11、开发一个Person类：它和普通的类没有什么不 同，但它符合bean的规范，即为每个属性提供 get,set方法 用xml映射文件描述其映射数据库的方式 编写Person.hbm.xml（ 建议命名为:“类名 ”+“hbm.xml”），并且放置在Person类相同包目录下 通过hibernate api对其持久化id(primary key)nameaddress 000000001阿三西安 . 为了运行要配置数据库：以mysql数据库 为例子：(只用劳动1次即可) hibernate.properties 在hibernate源程序 的根目录可以找到此文件模板，copy到我 们的类的根目录。

12、即：“.h” 该文件前两项都填好了，只用填数据库连 接和username,passwordhibernate.dialect net.sf.hibernate.dialect.MySQLDialect hibernate.connection.driver_class org.gjt.mm.mysql.Driver hibernate.connection.url jdbc:mysql:/localhost/test?useUnicode=true /* * A stateless session bean requesting that a remote * business interfa

13、ce be generated for it. */ Stateless Remote public class HelloWorldBean public String sayHello() return “Hello World“; 3. 轻量级框架和容器 自从EJB规范成型以来，很多事情已经变了样 EJB规范中的一些部分已经过时。 EJB和RMI之间那种传统的紧密关系也开始显得有些 不合时宜，这一方面是因为web services的迅速发展 ，另一方面是因为人们发现：很多时候EJB只需要本 地接口。 EJB最善于实现业务对象分布的体系结构，然而这种 体系结构究竟有多大程度的普遍性，如今看

14、来是相当 值得怀疑的。expert one-on-one J2EETM Development without EJB 中文版 从人们使用EJB的情况也可以看出EJB的优缺点。大 多数开发者和架构师仅仅使用无状态session bean（ SLSB）和（如果需要异步调用的话）message- driven bean（MDB）。EJB容器为支持SLSB而提供 的服务相当简单，这也就是说，对于这些应用程序来 说，整个EJB容器的高昂成本很难说是合理的。 尽管EJB已经存在了五年之久、并且在很多J2EE项 目中得到应用，但是很显然，由于它的复杂性，很多 开发者仍然没有真正理解它。譬如说，我所面试过的

15、 很多开发者都无法正确地说出EJB容器如何处理异常 ，自然也就更不清楚容器异常处理与事务管理之间的 关系了。 为了解决EJB存在的问题，EJB规范也在变得日益复 杂。如今，EJB规范是如此繁复冗长，几乎没有哪个 开发者或者架构师有时间去通读它，更不用说是理解 它了。就像应用程序一样，如果技术规范变得日益复 杂，并且需要不断地加入一些权宜之计，通常就说明 存在一些根本性的问题。 EJB是如此复杂，这也就意味着使用EJB的开发效率 会相对较低。有不少工具力图解决这个问题，从“企 业”IDE到XDoclet和其他代码生成工具，不一而足。 但这些工具只能把复杂性暂时掩盖起来，而且采用这 些工具也会增加

16、开发成本。 严格的单元测试和测试驱动开发（Test Driven Development，TDD）正在日益变得流行这也是 情理之中的。人们清楚地看到：大量使用EJB的应用 程序很难测试。用测试先行（test first）的方法开发 EJB应用需要做很多工作，因此，应当从根本上尽量 减少应用代码对EJB容器的依赖。 对于EJB致力解决的中间件问题，面向方面的程序设 计（Aspect Oriented Programming，AOP）的飞速 发展为我们指出了一条更为强大并且很可能更为 简单的解决之道。从某种意义上，AOP可以看作 EJB核心概念的更为广泛的应用，然而AOP还远不止 是EJB潜在的替