有关J2EE的流言ppt课件

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

2、的主流数据存储系统 对象和关系数据是业务虚体的两种表现方式 业务虚体在内存中表现为对象 在数据库中表现为关系数据 数据耐久化对象数据耐久化对象-关系映射方法：关系映射方法： Entity Bean 会话会话 bean 和和 JDBC JDO(Java Data Object) Hibernate iBatis , TopLink, Entity Bean 实体Bean作为企业数据耐久性机制具有如下优点： 规范化 透明的耐久性 事务支持 基于组件的设计 容器管理的效力。EJB 容器使开发人员不用管理常见的企业功能，如平安性、事务处置、衔接合用和外部资源管理。 实体 bean 的主要缺陷： 设计复

3、杂性。容器管理的效力和自动且透明的耐久性为整个运用程序设计引入了复杂性。实体 bean 通常也可以经过会话 bean 来访问，这意味着每个事务至少包含两个企业 bean，而通常会更多。 构建周期很长。一个 EJB 周期设计构建测试集成测试部署所花的时间比可比的 Java 耐久性处理方案多两到三倍。 呼应时间。实体 bean 与 bean 实例的粒度相关。因此，开发人员一直面临选择：要么将 bean 按原样装入，而在别的方面处理呼应时间长的问题；要么将数据分解成较小的实体，从而创建更复杂的系统体系构造。 资源运用情况。实体 bean 耗费了大量系统资源。会话 bean 和 JDBC 会话会话 b

4、ean 和和 JDBC 组合最受认可的优点如下：组合最受认可的优点如下： 设计简单。从体系构造设计观念来看，经过会话设计简单。从体系构造设计观念来看，经过会话 bean 来来直接处置数据管理比运用实体直接处置数据管理比运用实体 bean 简单得多。简单得多。 细粒度的控制。由于会话细粒度的控制。由于会话 bean 是通用的任务程序组件，是通用的任务程序组件，所以它们允许开发人员完全控制整个耐久性过程，包括高所以它们允许开发人员完全控制整个耐久性过程，包括高速缓存、耐久性、并发性、同步及其它。相反，速缓存、耐久性、并发性、同步及其它。相反，CMP 实实体体 bean 不允许开发人员控制耐久性机制

5、，而不允许开发人员控制耐久性机制，而 BMP 实体实体 bean 仅使开发人员可以定义应发生什么，而不能定义应仅使开发人员可以定义应发生什么，而不能定义应在何时或什么样的情况下发生。在何时或什么样的情况下发生。 成熟。成熟。JDBC 存在了七年左右！而实体存在了七年左右！而实体 bean 出现至今只出现至今只需三年多的时间。需三年多的时间。JDBC 的可靠性和最正确实际对于的可靠性和最正确实际对于 J2EE 耐久性机制的开发来说是一笔非常珍贵的资产。耐久性机制的开发来说是一笔非常珍贵的资产。 速度。由于开发人员完全控制在会话速度。由于开发人员完全控制在会话 bean 中运用的数据中运用的数据访

6、问机制，所以可以针对某些义务优化数据访问和耐久性访问机制，所以可以针对某些义务优化数据访问和耐久性逻辑。由于直接和有目的的操作，这可以产生极快的呼应逻辑。由于直接和有目的的操作，这可以产生极快的呼应时间。时间。 缺陷如下： 实现复杂。虽然这种系统的体系构造设计相当简单，但实践的会话 bean 实现经常非常复杂。假设运用程序的数据需求相当复杂，那么能够就无法实现管理数据库衔接、确保数据完好性以及正确处置事务语义这些关键义务。开发人员经常需求实现某种类型的高速缓存同时确保最优性能。构造这种高速缓存机制使该系统的开发和维护进一步复杂化。 非固有的事务性。实体 bean 本质上是事务性组件，这些组件具

7、有可配置的事务语义；而会话 bean 没有。将事务语义直接编码到运用程序代码中时，开发人员必需处处小心以确保每个功能的业务规那么、流控制和事务完好性都得以维护并且可以容错。在实体 bean 开发中，这些细节都由容器处置。 耐久性不是自动的或者得不到保证。在实体 bean 操作中，容器处置 bean 形状的耐久性，并确保这种数据得到维护，供以后运用。对于会话 bean，将数据坚持在平安、长期的数据存储中是开发人员的责任。 JDO(Java Data Object) JDO 提供了面向对象的耐久数据存储。开发人员运用 POJO无格式普通 Java 对象，plain ordinary Java ob

8、ject来装入和存储耐久数据。 会话 bean 与 JDO 结合类似于将它们与 JDBC 结合，但 JDO 是以更面向对象且更以 Java 为中心的观念处置该问题的。 会话 bean 和 JDO 提供了许多优点，其中有些来自会话 bean，而其它的来自 JDO，运用会话 bean 而不运用实体 bean 进展交付的主要优点有两个： 设计简单。从体系构造设计的观念来看，直接经过会话 bean 来处置数据管理比运用实体 bean 简单得多。 细粒度控制。由于会话 bean 是通用的任务程序组件，所以它们允许开发人员对整个耐久性进程进展完全控制，包括高速缓存、耐久性、并发性和同步等。 这两个优点并不

9、是会话 beanJDO 组合所特有的：会话 bean 与 JDBC 的结对也存在这两个优点。但是，JDO 确实提供了一些独特的优点： 编码简单。JDO 体系构造向开发人员隐藏了低级别的耐久性细节，从而使他们专注于从业务过程的角度管理对象，不至于堕入数据耐久性逻辑的琐碎细节中。 提高的消费力。JDO 程序员能完全在面向对象的范例内操作。这通常会使开发更简约、更平滑且更不易出错，由于程序员不用在关系的思想体系和面向对象的思想体系之间频繁地转换。 面向对象的耐久性。JDO 的面向对象本质不仅提高了开发人员消费力，而且它还思索到比关系耐久性所提供的还要丰富的耐久性机制。JDO 并不仅仅使 Java 对

10、象耐久；它还透明地处置整个相关对象图的耐久性。因此，当实例被耐久存储时，它所维护的对其它对象实例的任何内部援用也都被耐久存储除非它们已被声明为瞬态。JDO 还存储类型层次构造的完好信息，并能根据类型父类和接口实现恳求，而不是只了解耐久实例的特定部分类型。 缺陷： JDO 不成熟。JDO 还处于初期。到编写本文时，JDO 1.0 规范的发布还不到一年。其结果是，JDO 社区还非常小，最大且最具声威的 JDO 门户网站可以夸耀的也只是其会员有五千多一点。虽然这些数据并不表示 JDO 是一种差劲的技术，但它们确实阐明它还处于前沿。几乎没有几家公司情愿尝试在业务级实现中运用 JDO。 会话 bean

11、不是事务性的。J2EE 客户机不能直接访问 JDO 对象。必需由 servlet 或会话 bean 处置进入恳求。因此，虽然很容易将 JDO 对象声明为事务性的，但仍必需运用非事务性组件来访问它们。在将事务语义直接编码到会话 bean 的运用程序代码中时，开发人员必需尽一切能够确保每个功能的业务规那么、流程控制和事务完好性都得以保管并是容错的。虽然运用容器管理的事务可以极大地缓解这一问题，但是这样做限制了开发人员对耐久性进程的控制，并除去了许多控制事务粒度所产生的体系构造上的灵敏性。 Hibernate Persistent Object是简单的业务虚体对象(要被耐久化的对象)。经过hiber

12、nate被透明的耐久化到数据库中。 表person 开发一个Person类：它和普通的类没有什么不同，但它符合bean的规范，即为每个属性提供get,set方法 用xml映射文件描画其映射数据库的方式 编写Person.hbm.xml 建议命名为:“类名+“hbm.xml，并且放置在Person类一样包目录下 经过hibernate api对其耐久化id(primary key)nameaddress000000001阿三西安. 为了运转要配置数据库：以mysql数据库为例子：(只用劳动1次即可) perties 在hibernate源程序的根目录可以找到此文件模板，

13、copy到我们的类的根目录。即：“.h 该文件前两项都填好了，只用填数据库衔接和username,passwordhibernate.dialect net.sf.hibernate.dialect.MySQLDialecthibernate.connection.driver_class org.gjt.mm.mysql.Driverhibernate.connection.url jdbc:mysqllocalhost/test?useUnicode=true&characterEncoding=GBKhibernate.connection.username roothibern

14、ate.connection.password2. EJB 3.0 EJB1.0规范是在2019年提出，当时是为理处理CORBA的复杂性而提出的。EJB1.0规范中曾经承诺： EJB将简化开发人员的开发，开发人员不用理睬系统底层的事物和形状管理细节，以及多线程，资源池和其他的一些复杂的APIs。 EJB将遵照java的一次编写，处处运转的原那么，EJB只需求编写一次，就可以不加修正的和不需求重新编译的部署到其他恣意平台。 然而在实践运用中，EJB并没有兑现以上承诺。EJB从1.0规范到2.0规范变得越来越复杂，开发一个EJB必需实现一些与业务层无关的接口，还要维护冗长的XML配置文件。同时，各

15、个厂商还参与了一些本人特定的特性，当开发系统时运用了这些特性后，将无法实现各个效力器之间的平滑移植。 为此，专家组对原有的EJB规范进展了大刀阔斧的改良，提出了新的EJB3.0规范。 EJB 2.x的复杂性的复杂性 冗长的冗长的XML配置文件配置文件 EJB的一切配置信息都在的一切配置信息都在XML文件中，如一个文件中，如一个EJB的的local接口，接口，remote接口和接口和Bean实现类的实现类的指定，都是经过指定，都是经过ejb-jar.xml中配置来完成的。由中配置来完成的。由于于XML文件是基于文本的，所以开发者在编写文件是基于文本的，所以开发者在编写XML文件的时候往往会犯一些

16、小错误的，例如：文件的时候往往会犯一些小错误的，例如：大小写，多写，漏写字母等。但是这种简单的错大小写，多写，漏写字母等。但是这种简单的错误在编译的时候是不会被发现的，只需在部署的误在编译的时候是不会被发现的，只需在部署的时候才干发现。这样使得调试时候才干发现。这样使得调试EJB变得非常的繁变得非常的繁琐，降低了开发效率。琐，降低了开发效率。 开发开发EJB不但要编写不但要编写ejb=jar.xml文件，还需求一文件，还需求一个运用效力器特有的部署描画文件。然而，每个个运用效力器特有的部署描画文件。然而，每个厂商的运用效力部署效力器的配置文件都是不同厂商的运用效力部署效力器的配置文件都是不同的

17、，这样就带来一个问题，当把一个的，这样就带来一个问题，当把一个EJB运用从运用从一个效力器移植到另一个效力器时，就必需修正一个效力器移植到另一个效力器时，就必需修正相应的配置文件。相应的配置文件。EJB的实现类不是的实现类不是POJO Plain Ordinary Java Objects 在在EJB2.x规范下开发规范下开发EJB，即使是最简，即使是最简单的单的helloworld程序，我们都至少编写程序，我们都至少编写3个类文件，分别是个类文件，分别是Bean类，类，Home接口和接口和Remote接口。这些类和接口必需承继或接口。这些类和接口必需承继或实现规范中所定义的接口，并且要实现一

18、实现规范中所定义的接口，并且要实现一些在业务逻辑中不会运用的回调函数，如些在业务逻辑中不会运用的回调函数，如ejbCreate(),ejbPassivate()等等。等等。EJB的复杂调用过程的复杂调用过程在在EJB2.x规范下，规范的规范下，规范的EJB调用过程调用过程可以描画为：调用者经过可以描画为：调用者经过JNDI查找想要查找想要调用的调用的EJB的的home接口，运用者经过前接口，运用者经过前往的往的home接口创建相应的接口创建相应的remote接口，接口，经过前往的经过前往的remote接口才干调用实现业接口才干调用实现业务逻辑的方法，这样的调用过程不仅在远务逻辑的方法，这样的调

19、用过程不仅在远程调用时运用，即使在同一容器的程调用时运用，即使在同一容器的jsp中，中，甚至在一个甚至在一个ejb调用另外一个调用另外一个ejb时，都要时，都要进展同样的调用过程。进展同样的调用过程。实体实体Bean的局限性的局限性在在EJB2.x规范中，实体规范中，实体bean分为两种：分为两种：CMP和和BMP。BMP由于需求用户去维护由于需求用户去维护耐久化任务和维护耐久化任务和维护EJB形状，开发者需求形状，开发者需求做很多繁琐任务。与传统的做很多繁琐任务。与传统的JDBC方式相方式相比，并没有带来太多的便利，同时还要实比，并没有带来太多的便利，同时还要实现不用要的容器组件接口。现不用

20、要的容器组件接口。 EJB3.0规范中主要涉及两个方面的改动： 一套以注释为根底的EJB编程模型，再加上EJB2.1中定义的经过布署描画符合几个接口定义的运用程序行为。 新的实体Bean耐久化模型，EJBQL也有许多重要的改动。EJB3.0的简约性的简约性 EJB注释： EJB规范组织一个重要的目的是减轻原始代码的数量，并且他们为此给出了一个相当简约的方法。 在EJB3.0里，任何类型的企业级Bean只是一个加了适当注释的简单Java对象(POJO)。 注释可以用于定义bean的业务接口、O/R映射信息、资源援用信息，效果与在EJB2.1中定义部署描画符和接口是一样的。 在EJB3.0中部署描

21、画符不再是必需的了，home接口也没有了，也不用实现业务接口容器可以为他完成这些事情。 比如， 可以运用Stateless注释标志类把Java类声明为一个无形状会话bean。 对于有形状会话bean来说，Remove注释可以用来标志一个特定的方法，经过这个注释来阐明在调用这个方法之后bean的实例将被去除掉。 为了减少描画组件的阐明信息，规范组织还采用了由异常进展配置configuration-by-exception的手段，意思是他可以为一切的注释提供一个明确的缺省值，这样多数常规信息就可以据此推断得出。 在EJB3.0规范中，写一个无形状会话bean只需求一个简单的Java文件并在类层加上

22、Stateless注释就可以了。 这个bean可以扩展javax.ejb.SessionBean接口，但这些不是必需的。 一个无形状会话bean不再需求home接口，没有哪类EJB再需求它了。 Bean类可以实现业务接口也可以不实现它。 假设没有实现任何业务接口，业务接口会由恣意public的方法产生。 假设只需几个业务方法会被暴露在业务接口中，这些方法可以运用BusinessMethod注释。 缺省情况下一切产生的接口都是local本地接口，他也可以运用Remote注释来声明这个接口为remote远程接口。import javax.ejb.*;/* A stateless session b

23、ean requesting that a remote * business interface be generated for it.*/StatelessRemotepublic class HelloWorldBean public String sayHello() return Hello World;3. 轻量级框架和容器轻量级框架和容器 自从EJB规范成型以来，很多事情曾经变了样 EJB规范中的一些部分曾经过时。 EJB和RMI之间那种传统的严密关系也开场显得有些不合时宜，这一方面是由于web services的迅速开展，另一方面是由于人们发现：很多时候EJB只需求本地接口。

24、 EJB最擅长实现业务对象分布的体系构造，然而这种体系构造终究有多大程度的普遍性，如今看来是相当值得疑心的。expert one-on-one J2EETM Development without EJB 中文版 从人们运用EJB的情况也可以看出EJB的优缺陷。大多数开发者和架构师仅仅运用无形状session beanSLSB和假设需求异步伐用的话message-driven beanMDB。EJB容器为支持SLSB而提供的效力相当简单，这也就是说，对于这些运用程序来说，整个EJB容器的高昂本钱很难说是合理的。 虽然EJB曾经存在了五年之久、并且在很多J2EE工程中得到运用，但是很显然，由于它

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

26、掩盖起来，而且采用这些工具也会添加开发本钱。 严厉的单元测试和测试驱动开发Test Driven Development，TDD正在日益变得流行这也是情理之中的。人们清楚地看到：大量运用EJB的运用程序很难测试。用测试先行test first的方法开发EJB运用需求做很多任务，因此，该当从根本上尽量减少运用代码对EJB容器的依赖。 对于EJB努力处理的中间件问题，面向方面的程序设计Aspect Oriented Programming，AOP的飞速开展为我们指出了一条更为强大并且很能够更为简单的处理之道。从某种意义上，AOP可以看作EJB中心概念的更为广泛的运用，然而AOP还远不止是EJB潜在

27、的替代品，它还有更多的潜力可挖。 在大多数时候，源代码级的元数据属性就像.NET中所运用的那样可以非常优雅地取代基于XML的部署描画符从EJB 1.1起，我们就不断在跟这些冗长的XML文件周旋。EJB 3.0似乎曾经开场朝着这个方向努力了，但它背负着如此繁重的历史包袱，需求走的路还很长。 阅历还阐明，EJB往往招致更高的开发本钱，并且提供的利益也并不像它最初所鼓吹的那么丰富。 根据我们的阅历，EJB的失败之处主要有以下几点： EJB并非降低复杂度所必需的，它倒是引入了很多新的复杂度。 作为一种耐久化机制，entity bean的尝试是彻底失败的。 与其他J2EE技术例如servlet相比，运用

28、EJB的运用程序更加缺乏不同运用效力器之间的可移植性。 虽然EJB承诺提供高度可伸缩性，然而EJB系统的性能经常不够理想，而且EJB也并不是获得可伸缩性所必需的。虽然很难得到准确的统计数据，但实践阅历通知我们：有相当一部分工程正是由于过度运用EJB而不得不重新进展架构设计，甚至是彻底失败。 EJB能够让简单的事情变得困难。譬如说，Singleton设计方式或者与之类似的创建型方式就很难在EJB环境下实现。 只需在提供远程调用remoting这件事上，EJB是规范J2EE架构中独一的实现方式。不过，正如我们将要看到的，只需在RMI/IIOP远程调用的领域里，EJB才算得上一种出色的实现技术 对于

29、那些真正需求对象分布的运用，EJB依然是上佳之选尤其是当它们完全用Java实现、或者用IIOP作为通讯协议时。不过，这种运用比人们通常想象的要稀有得多。 EJB不是J2EE的全部。即使运用没有EJB的J2EE，我们也无须重新发明轮子我们不用重新实现J2EE曾经提供的效力，只是改动运用它们的方式而已。 轻量级框架轻量级框架 Spring Pico HiveMind Proposed Web App Layering Presentation/Business/Persistence Struts+Spring+Hibernate Struts + Spring + EJB JavaServer

30、Faces + Spring + iBATIS Spring + Spring + JDO Flex + Spring + Hibernate Struts + Spring + JDBC You decideMore Application Layering CombinationsSuns traditional solution to middle tier business logicSpecification that did not always work as projected in real applications.EJBs are less portable than P

31、OJO based architectures. Inconsistencies by vendors make EJBs break the “write once, run anywhere rule.Fosters over-engineering in most casesEntity Beans very limiting compared to alternatives such as Hibernate.Performance with POJOs are much faster then EJBs.EJBs run in a heavy containerYour code becomes coupled to EJB API.We need to redefine what J2EE meansEJB (=2.x) in the Service LayerSpring - IOC IOC，即控制反转方式也称作依赖性介入，这是Spring的中心，也是精华。 其根本概念是： 不创建对象，但是描画创建它们的方式。 在代码中不直接与对象和效力衔接，但在配置文件中描画哪一个组件需求哪一项效力。 容器 在 Spring 框架中是 IOC 容器 担任将这些联络在一同。 传统的程序开发，在一个对象中，假设要运用另外的对象