有关J2EE的流言课件

声明本课件修改采用了一些网络资源（论文、研究报告、技术报告等），在采用的时候并没有准确标注引用信息。有关J2EE的流言1.关系-对象映射2.EJB的简化3.轻量级框架和容器数据持久化（对象-关系映射）方法：EntityBean会话bean和JDBC

JDO(JavaDataObject)HibernateiBatis,TopLink,……EntityBean实体Bean作为企业数据持久性机制具有如下优点：标准化透明的持久性事务支持

基于组件的设计容器管理的服务。EJB容器使开发人员不必管理常见的企业功能，如安全性、事务处理、连接合用和外部资源管理。实体bean的主要缺点：设计复杂性。容器管理的服务和自动且透明的持久性为整个应用程序设计引入了复杂性。实体bean通常也可以通过会话bean来访问，这意味着每个事务至少包含两个企业bean，而通常会更多。构建周期很长。一个EJB周期（设计／构建／测试／集成／测试／部署）所花的时间比可比的Java持久性解决方案多两到三倍。响应时间。实体bean与bean实例的粒度相关。因此，开发人员始终面临选择：要么将bean按原样装入，而在别的方面解决响应时间长的问题；要么将数据分解成较小的实体，从而创建更复杂的系统体系结构。资源使用情况。实体bean消耗了大量系统资源。缺点如下：实现复杂。虽然这种系统的体系结构设计相当简单，但实际的会话bean实现常常十分复杂。如果应用程序的数据需求相当复杂，那么可能就无法实现管理数据库连接、确保数据完整性以及正确处理事务语义这些关键任务。开发人员常常需要实现某种类型的高速缓存同时确保最优性能。构造这种高速缓存机制使该系统的开发和维护进一步复杂化。非固有的事务性。实体bean本质上是事务性组件，这些组件具有可配置的事务语义；而会话bean没有。将事务语义直接编码到应用程序代码中时，开发人员必须处处小心以确保每个功能的业务规则、流控制和事务完整性都得以保护并且可以容错。在实体bean开发中，这些细节都由容器处理。持久性不是自动的或者得不到保证。在实体bean操作中，容器处理bean状态的持久性，并确保这种数据得到保护，供以后使用。对于会话bean，将数据保持在安全、长期的数据存储中是开发人员的责任。JDO(JavaDataObject)JDO提供了面向对象的持久数据存储。开发人员使用POJO（无格式普通Java对象，plainordinaryJavaobject）来装入和存储持久数据。会话bean与JDO结合类似于将它们与JDBC结合，但JDO是以更面向对象且更以Java为中心的观点处理该问题的。会话bean和JDO提供了许多优点，其中有些来自会话bean，而其它的来自JDO，使用会话bean而不使用实体bean进行交付的主要优点有两个：设计简单。从体系结构设计的观点来看，直接通过会话bean来处理数据管理比使用实体bean简单得多。细粒度控制。因为会话bean是通用的工作程序组件，所以它们允许开发人员对整个持久性进程进行完全控制，包括高速缓存、持久性、并发性和同步等。缺点：JDO不成熟。JDO还处于初期。到编写本文时，JDO1.0规范的发布还不到一年。其结果是，JDO社区还非常小，最大且最具威望的JDO门户网站可以炫耀的也只是其会员有五千多一点。尽管这些数据并不表示JDO是一种差劲的技术，但它们确实表明它还处于前沿。几乎没有几家公司愿意尝试在业务级实现中使用JDO。会话bean不是事务性的。J2EE客户机不能直接访问JDO对象。必须由servlet或会话bean处理进入请求。因此，尽管很容易将JDO对象声明为事务性的，但仍必须使用非事务性组件来访问它们。在将事务语义直接编码到会话bean的应用程序代码中时，开发人员必须尽一切可能确保每个功能的业务规则、流程控制和事务完整性都得以保留并是容错的。尽管使用容器管理的事务可以极大地缓解这一问题，但是这样做限制了开发人员对持久性进程的控制，并除去了许多控制事务粒度所产生的体系结构上的灵活性。HibernatePersistentObject是简单的业务实体对象(要被持久化的对象)。通过hibernate被透明的持久化到数据库中。表person开发一个Person类：它和普通的类没有什么不同，但它符合bean的规范，即为每个属性提供get,set方法用xml映射文件描述其映射数据库的方式编写Person.hbm.xml（建议命名为:“类名”+“hbm.xml”），并且放置在Person类相同包目录下通过hibernateapi对其持久化id(primarykey)nameaddress000000001阿三西安...

2.EJB3.0EJB1.0规范是在1997年提出，当时是为了解决CORBA的复杂性而提出的。EJB1.0规范中曾经承诺：EJB将简化开发人员的开发，开发人员不必理会系统底层的事物和状态管理细节，以及多线程，资源池和其他的一些复杂的APIs。EJB将遵循java的一次编写，处处运行的原则，EJB只需要编写一次，就能够不加修改的和不需要重新编译的部署到其他任意平台。然而在实际应用中，EJB并没有兑现以上承诺。EJB从1.0规范到2.0规范变得越来越复杂，开发一个EJB必须实现一些与业务层无关的接口，还要维护冗长的XML配置文件。同时，各个厂商还加入了一些自己特定的特性，当开发系统时使用了这些特性后，将无法实现各个服务器之间的平滑移植。为此，专家组对原有的EJB规范进行了大刀阔斧的改进，提出了新的EJB3.0规范。EJB2.x的复杂性冗长的XML配置文件EJB的所有配置信息都在XML文件中，如一个EJB的local接口，remote接口和Bean实现类的指定，都是通过ejb-jar.xml中配置来完成的。由于XML文件是基于文本的，所以开发者在编写XML文件的时候往往会犯一些小错误的，例如：大小写，多写，漏写字母等。但是这种简单的错误在编译的时候是不会被发现的，只要在部署的时候才能发现。这样使得调试EJB变得非常的繁琐，降低了开发效率。开发EJB不但要编写ejb=jar.xml文件，还需要一个应用服务器特有的部署描述文件。然而，每个厂商的应用服务部署服务器的配置文件都是不同的，这样就带来一个问题，当把一个EJB应用从一个服务器移植到另一个服务器时，就必须修改相应的配置文件。EJB的复杂调用过程在EJB2.x规范下，标准的EJB调用过程可以描述为：调用者通过JNDI查找想要调用的EJB的home接口，使用者通过返回的home接口创建相应的remote接口，通过返回的remote接口才能调用实现业务逻辑的方法，这样的调用过程不仅在远程调用时使用，即使在同一容器的jsp中，甚至在一个ejb调用另外一个ejb时，都要进行同样的调用过程。实体Bean的局限性在EJB2.x规范中，实体bean分为两种：CMP和BMP。BMP由于需要用户去维护持久化工作和维护EJB状态，开发者需要做很多繁琐工作。与传统的JDBC方式相比，并没有带来太多的便利，同时还要实现不必要的容器组件接口。

EJB3.0规范中主要涉及两个方面的改变：

一套以注释为基础的EJB编程模型，再加上EJB2.1中定义的通过布署描述符合几个接口定义的应用程序行为。

新的实体Bean持久化模型，EJBQL也有许多重要的改变。EJB3.0的简洁性

在EJB3.0规范中，写一个无状态会话bean只需要一个简单的Java文件并在类层加上@Stateless注释就可以了。这个bean可以扩展javax.ejb.SessionBean接口，但这些不是必须的。一个无状态会话bean不再需要home接口，没有哪类EJB再需要它了。Bean类可以实现业务接口也可以不实现它。如果没有实现任何业务接口，业务接口会由任意public的方法产生。如果只有几个业务方法会被暴露在业务接口中，这些方法可以使用@BusinessMethod注释。缺省情况下所有产生的接口都是local（本地）接口，你也可以使用@Remote注释来声明这个接口为remote（远程）接口。 importjavax.ejb.*; /**

*Astatelesssessionbeanrequestingthataremote

*businessinterfacebegeneratedforit.

*/

@Stateless

@Remote

publicclassHelloWorldBean{

publicStringsayHello(){

return"HelloWorld";

}

}EJB是如此复杂，这也就意味着使用EJB的开发效率会相对较低。有不少工具力图解决这个问题，从“企业”IDE到XDoclet和其他代码生成工具，不一而足。但这些工具只能把复杂性暂时掩盖起来，而且采用这些工具也会增加开发成本。严格的单元测试和测试驱动开发（TestDrivenDevelopment，TDD）正在日益变得流行——这也是情理之中的。人们清楚地看到：大量使用EJB的应用程序很难测试。用测试先行（testfirst）的方法开发EJB应用需要做很多工作，因此，应当从根本上尽量减少应用代码对EJB容器的依赖。对于EJB致力解决的中间件问题，面向方面的程序设计（AspectOrientedProgramming，AOP）的飞速发展为我们指出了一条更为强大——并且很可能更为简单——的解决之道。从某种意义上，AOP可以看作EJB核心概念的更为广泛的应用，然而AOP还远不止是EJB潜在的替代品，它还有更多的潜力可挖。在大多数时候，源代码级的元数据属性（就像.NET中所使用的那样）可以非常优雅地取代基于XML的部署描述符——从EJB1.1起，我们就一直在跟这些冗长的XML文件周旋。EJB3.0似乎已经开始朝着这个方向努力了，但它背负着如此沉重的历史包袱，需要走的路还很长。经验还表明，EJB往往招致更高的开发成本，并且提供的利益也并不像它最初所鼓吹的那么丰富。根据我们的经验，EJB的失败之处主要有以下几点：EJB并非降低复杂度所必须的，它倒是引入了很多新的复杂度。作为一种持久化机制，entitybean的尝试是彻底失败的。与其他J2EE技术（例如servlet）相比，使用EJB的应用程序更加缺乏不同应用服务器之间的可移植性。尽管EJB承诺提供高度可伸缩性，然而EJB系统的性能常常不够理想，而且EJB也并不是获得可伸缩性所必须的。尽管很难得到准确的统计数据，但实际经验告诉我们：有相当一部分项目正是因为过度使用EJB而不得不重新进行架构设计，甚至是彻底失败。EJB可能让简单的事情变得困难。譬如说，Singleton设计模式（或者与之类似的创建型模式）就很难在EJB环境下实现。只有在提供远程调用（remoting）这件事上，EJB是标准J2EE架构中唯一的实现方式。不过，正如我们将要看到的，只有在RMI/IIOP远程调用的领域里，EJB才算得上一种出色的实现技术对于那些真正需要对象分布的应用，EJB仍然是上佳之选——尤其是当它们完全用Java实现、或者用IIOP作为通信协议时。不过，这种应用比人们通常想象的要罕见得多。EJB不是J2EE的全部。即便使用没有EJB的J2EE，我们也无须重新发明轮子——我们不必重新实现J2EE已经提供的服务，只是改变使用它们的方式而已。轻量级框架Spring

PicoHiveMind

ProposedWebAppLayeringPresentation/Business/PersistenceStruts+Spring+HibernateStruts+Spring+EJBJavaServerFaces+Spring+iBATISSpring+Spring+JDOFlex+Spring+HibernateStruts+Spring+JDBCYoudecide…MoreApplicationLayeringCombinationsSun’straditionalsolutiontomiddletierbusinesslogicSpecificationthatdidnotalwaysworkasprojectedinrealapplications.EJBsarelessportablethanPOJObasedarchitectures.InconsistenciesbyvendorsmakeEJBsbreakthe“writeonce,runanywhere”rule.Fostersover-engineeringinmostcasesEntityBeans–verylimitingcomparedtoalternativessuchasHibernate.PerformancewithPOJOsaremuchfasterthenEJBs.EJBsruninaheavycontainerYourcodebecomescoupledtoEJBAPI.WeneedtoredefinewhatJ2EEmeans…EJB(<=2.x)intheServiceLayerSpring-IOCIOC，即控制反转模式（也称作依赖性介入），这是Spring的核心，也是精髓。其基本概念是：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器（在Spring框架中是IOC容器）负责将这些联系在一起。传统的程序开发，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象。这一点是通过DI（DependencyInjection，依赖注入）来实现的。在典型的IOC场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，决定什么时间调用方法。下表列出了IOC的一个实现模式。Spring框架的IOC容器采用类型2和类型3实现。类型1服务需要实现专门的接口，通过接口，由对象提供这些服务，可以从对象查询依赖性（例如，需要的附加服务）类型2通过JavaBean的属性（例如setter方法）分配依赖性类型3依赖性以构造函数的形式提供，不以JavaBean属性的形式公开MiddleTier:SetterInjectionpublicclassServiceImplimplementsService{ privateinttimeout; privateAccountDaoaccountDao;publicvoidsetTimeout(inttimeout){ this.timeout=timeout;}publicvoidsetAccountDao(AccountDaoaccountDao){ this.accountDao=accountDao;}//BusinessmethodsfromService

…<beanid="service"class="com.mycompany.servic