应用程序时,根据具体业务需求的不同,EJB规范2.1又定义了3类啪: (1)会话EJB:主要用于封装业务逻辑。
会话EJB中的数据并不自动同步于底层的持久性存储器。
会话bean又分为两类。
有状态的会话EJB能够通过方法调用来存储客户机特有的数据,反之,无状态的会话E膪不能够存储该数据。
物流仓库管理系统 (2)实体EJB:也是用于封装业务逻辑。
但是,实体EJB的数据与底层的持久性存储器同步。
同步过程可以完全受控于容器,称为容器管理的持久性(C0ntainer—mamgedPersistence,CMP),或者部分受控于EJB代码,称为实体管理的持久性(Beall一ma眦gedPersistcnce,BⅣ口1。
(3)消息驱动EJB:消息驱动EJB是EJB 2.O中新引入的,它支持异步通信。
会话和实体EJB支持同步同步通信,也就是说,当客户机调用EJB方法时必须等待EJB返回结果,如同常规的Java方法调用。
由此可见,三类E旧在特性、’功能和地位上有着本质的区别,而EJB容器为它们提供支持和服务的时候,发现有些服务在一般的web应用中显得笨重多余【8】。
其主要缺陷如下: (11编写一个Em非常复杂:为了编写一个EJB,
系统必须实现4个文件:业务接口、Home接口、BeaIl实现和部署描述文件。
还需要引入一些其它类,如工具类和数据对象类。
当系统使用很少的几项服务时,这使得系统的性能降低、复杂度变高。
(21 EJB是侵入式的:这与前一点有关系。
为了使用EJB容器提供的服务,程序必须使用iava)(.ejb中的一些接口。
这样就把组件代码绑定到了EJB技术上了,要在EJB容器外使用该组件就变得很困难了,甚至于不可能。
(3)Ent时哪的不足:作为事实上的O瓜映射方案,E埘ty EJB没有其他ORM工具那么灵活。
对于BMP是在Bean中完成对数据库JDBC的各种调用,也就是在实体Bean中明确写入了s0L语句,这种做法对系统的可维护性产生困难。
而采用cMP,它虽然是由EJB容器自动完成对数据库的操作,编写起来相对而言要简单一些,但是它不够灵活,比如要实现类似sQL
搜索语句的like命令,就比较困难【9】。
事实上,这也是本论文采用第三方O瓜映射工具Hibemate的重要理由之一。
依据以上分析,虽然E毋提供了透明的持久性、可移植性和灵活的事务管理,但是获得这些优点所付出的代价就是会引入复杂性和很长的构建周期,从而使包含它们的系统设计和开发更加困难。
可见在有些项目中运用诸如EJB等重量级框架并不是明智之举。
针对上述
问题,类似Picoconta协er、HiveM砌及s埘ng这样的轻量级框架应运而生,所谓的“轻量级”,并不是“功能少、设计简陋、实现粗糙”的代名词。
它的设计哲学是“许多的应用不需要分布式,有必要将大多数应用中不必要的技术隔离、改造。
完全可以针对最常见、最简单的应用场景而设计,等到有特殊需求的时候,再想办法解决问题”。
同时在持久层上,E商ty EJB解决对象关系映射方面效果不是很好,在实际的开发过程中完全可以采用第三方工具,比如Hibemate、TopLink及Torque等。
大连理工大学专业学位硕士学位论文1.3论文的工作和章节安排 本论文是从现阶段基于MVC模式的web应用开发中存在的问题入手,主要针对目前主流厂商提供的J2EE平台的业务逻辑层解决方案E喝机制的一些不足,找到符合企业级应用软件系统需求特点的开发方法,并在实际中进行检验。
本论文的意义在于,在项目的具体实现中没有采用J2EE平台的业务逻辑层解决
方案E腰机制,而是采用spring轻量级框架。
同时,由于在目前的Mvc框架中,strL鹏已经逐渐成长为一个稳定、成熟的框架,并且占有了MvC框架中最大的市场份额,所以本系统将s仃吐s框架跟s皿吨框架做了一个整合,使它们在表示层、控制层以及业务逻辑层上协同工作。
在持久层的设计上本系统采用了开源的持久层框架Hibemate。
总之,本