周警?BR>
一Q?设计模式重要?BR>采用QＪQ技术的Q２QI目中，QＪQ架构的设计好坏直接媄响系l的性能、可扩展性、可l护性、组件可重用性及开发效率。项目越复杂Q项目队伍越庞大则越能体现良好设计的重要性?
二． 常见EJB设计模式
Session Facade Pattern
通常目中，客户端往往需要频J的Ҏ(gu)务器端数据进行操作。当采用实体QＪQ作为数据的抽象层时Q如果直接让客户端程序与实体QＪQ交互，会生实C个业务需求便需要大量的QＪQ属性操作（如下图１Q。这直接D如下问题Q网l负载大Q远E客L(fng)Ӟ、ƈ发性能低、客L(fng)与服务器端关联度大、可重用性和可维护性差、性能
因此有必要在客户端与实体QＪQ层间加入Session QＪQ层Q在Sessino EJB中实现商业逻辑q封装对实体QＪQ的操作。（如下图２Q?BR>
图１Q客L(fng)直接与实体IQ交互
图２Q通过SessionEJB层实?BR>Session Fa?ade模式的好处是Q降低了|络负蝲QSessionEjb可以调用实体QＪQ的本地接口Q将商业逻辑与商业数据隔；l护与开发方便；显著提高性能?BR>Session Fa?ade模式因其单用，是目前用很q的模式。但具体应用q程中应注意Q避免将所有的操作装C个很大的SessionEJB内；服务器端数据l构应由实体EJB实现,除非特例否则避免直接的数据库操作QSessionEjb内某些系l通用操作的代码容易重复（比如权限查等Q解军_法是系l通用服务装在Java Class内）?/P>
Message Facade Pattern
很多时候，一ơRequest需要操作多个IQ又不需要得到即时返回。对q种异步调用Q通常应用Message Fa?ade Pattern.
q种时候，如采用Session Fa?ade Pattern存在如下问题Q?BR>1. 客户端等待返回的旉q长。一个SessionEjb的实例在完成客户hq程中中涉及到的每一ơ对其他实体Ejb的调用过E中都会被锁定直到得到实体EJBq回信息后才能进行下一步操作。这样造成客户不必要的{待Qƈ很容易因旉D整个事务p|?BR>2. pȝ可靠性和定w性低。如果需要调用不同系l或服务器上或多个异构数据源的多个IQӞM一个环节出错，均导致客戯求失败?BR>以Message-Driven Bean为基的Message Facade Pattern则可以解决上q异步请求需求。具体架构见下图Q?
图３Q用Message Facade Pattern
Message Facade Pattern的不之处在于：
Q． Message-Driven Bean没有q回倹{这样通知客户执行l果只能依赖于Iｍａｉｌ或h工等其他手段?BR>Q． Message-Driven Bean执行q程中无法将捕获的异常直接返回给客户端，x法客户端直接直到错误信息?BR>Q． Message-Driven Bean通过接收Message响应客户hQ对Message内容的合法性（比如对象的类型等Q依赖与客户?Ҏ(gu)产生q行旉误?BR>Message Facade Patternl常与Session Facade Pattern在同一个项目里共同使用?/P>
EJB Command Pattern
Session Facade Pattern中将商业逻辑实现装在Session EJB中，q种做法带来诸多益处之外也带来如下问题：
Q． ׃业务l常的变化，Dl常需要更新Session EJB代码?BR>Q． 客户端代码不得不包含大量EJB相关的ＡQ;Q不利于后期目l护?BR>Q． 目开发测试需要经常的EJB重部|过E?BR>引v上述问题的重要根l就是Session EJB本n重量U组Ӟ其开发测试部|工作量较大Q开发周期较ѝ以上不_以通过EJB Command Pattern克服?BR>EJB Command Pattern中将商业逻辑实现装在普通的Java ClassQ称之ؓCommand BeanQ中。该模式的具体实现有很多U，通常的框枉包括三部分：
Q． Command Bean.由应用开发者写的具体实现某商业操作的Java Class.主要包含getXXX(),setXXX(),execute()Ҏ(gu)?BR>Q． Client-Side Routing Logic.由多个Classl成Q用于将h转发?B style="COLOR: black; BACKGROUND-COLOR: #ffff66">Command SeverQ这个过E对客户是透明的。这部分代码可以跨项目用。\p则中可以考虑用QＬ技术?BR>Q． Remote Command Server.实际执行商业操作h。通常可以用Session EJB层实现?/P>
整个框架见下图４Q?BR>
图４Q?B style="COLOR: black; BACKGROUND-COLOR: #ffff66">Command的基本框?BR>EJB Command Patternh如下好处Q?BR>Q． 适应与需要快速开发环境。因Command Bean是轻量的Java ClassQ其~译和调试比较方ѝ?BR>Q． 表现层与商业实现层隔离Q同时将客户端代码与EJB层隔R?BR>Q． 客L(fng)代码开发与服务器端代码开发相Ҏ(gu)晰。早期可以创建空?B style="COLOR: black; BACKGROUND-COLOR: #ffff66">Command Bean方便客户端代码调试?BR> EJB Command Pattern的弱处在于：
Q． Command Bean中对事务的控制不如Session EJB中?BR>Q． Command Bean是无状态的?BR>Q． 无法异常直接返回给客户?BR>Q． 在大目中，׃商业逻辑复杂Q常D大数量的Command Bean存在.
Q． 作ؓCommand Server的Session EJB打包时必d?B style="COLOR: black; BACKGROUND-COLOR: #ffff66">Command Bean以致存在l护上的不便?BR> EJB Command Pattern的一个实际实现可以参考IBM's Command Framework.
Data Transfer Object Factory
ZEJB的J2EE目Q经帔R要在客户端与服务器端传输大量数据。数据的l织形式常用的是DTO(Data Transfer ObjectQ服务器端数据对象的抽象)。但因ؓ客户端表现层l常是变化的Q所需要服务器端数据也变动频繁Q换句话_DTO的数量和属性经常要更改。因此如何以及在何处生成和维护DTO便是需要考虑的问题?BR>一U解x案是直接在Entity EJB中直接处理，卛_Entity EJB的BeancM加入getXXXDTO()、setXXXDTO(){。但q样做导致EJB与DTO层紧紧绑定。一旦DTO更改Q与该DTO相关的EJB即需要重~译打包。EJB层与客户端层相关联不仅ɾl护困难而且DEJB的重用性大大降低?BR>更好的解x案是利用Data Transfer Object Factory装对DTO的操作逻辑Q如下图Q）?BR>
图６QDTO FactoryCZ
DTO Factory具体实现方式通常有两U：
Q． 普通Java Class实现Q用于Session Facade Pattern使用DTO环境下?BR>Q． Stateless Session EJB实现Q用于非EJB客户端用DTO环境下（见图Q）?BR>
图７QSessionEJB实现DTOFactory
DTO Factory带来如下好处Q?BR>Q． 使Entity EJB的重用成为可能。由于不含DTO处理逻辑QEntity EJB功能单一化，只作为数据源。不通客L(fng)通过各自的DTO Factory可以从同一个Entity EJB得到各自所需的个性化数据Q自定义DTOQ?BR>Q． 提高可维护性和性能?BR>Q． 可以Ҏ(gu)在DTO Factory层生成很复杂的DTOl构Q诸如ѝ关联关pȝQ而对客户端提供一个透明、细化的数据接口?BR> 使用DTO Factory旉要注意的是：不需为每个Entity EJB定义一个Factory。可以ؓ一pd相关的Entity EJB创徏一个FactoryQ或者只创徏一个Factory?/P>
Generic Attribute Access
使用Entity EJB作ؓ商业数据层时Q我们首先需要从数据库加载数据，创徏对应的Entity EJB实例Q之后对内存中Entity EJB实例的属性进行相应操作。对属性的操作比较直接的做法是Q直接调用Entity EJB的getXXX()/setXXX()Q通常利用EJB2.0的本地接口；通过DTO Factory生成DTO。但q两U做法都存在如下问题Q?BR>Q． 当Entity EJB的属性特别多时候，以上做法会带来复杂罗嗦的代码QEJB变的庞大无比?BR>Q． 使Entity EJB的客L(fng)Q比如Session EJBQ和Entity EJB的接口紧密关联。Entity EJB属性的增删都需要更改客L(fng)代码Q给目开发和l护带来不便?BR>事实上可以利用更通用的方式访问Entity EJB的属性，卛_义Generic Attribute Access Interface。见下图Q：
图８QGeneric Attribute Access InterfaceCZ
Generic Attribute Access Interface由Entity EJB的本地或q程接口实现Qƈ利用Hash Maps传输数据。实现方式常见如下：
Q． BMPcd实体EJB可以在BeancM定义包含所有属性的U有成员变量HashMap?BR>Q． CMPcd实体EJB可以在BeancM可以适用Java Reflection API实现?BR>Q． 建立一个父c，在不同的情况下定义子c重载父cL法?BR>使用Generic Attribute Access Interface需要在客户端与服务器端对属性以及对应的关键字徏立统一的命名习(fn)惯。常见的做法如下Q?BR>Q． 建立q保持良好的文档记录和命名约定?BR>Q． 在实体EJB的实现类中定义静态成员映属性?BR>Q． 创徏׃n静态类Q通过成员变量映射实体EJB属性?BR>Q． 通过JNDI在服务器端保存属性映关pR?BR>Generic Attribute Access Interface的运用带来一下益处：
Q． 接口实现后对不通实体EJB都适用?BR>Q． 对属性较多实体EJB能精代码Qƈ更具l护性?BR>Q． 使运行中动态增删实体EJB属性成为可能?BR>Generic Attribute Access Interface的缺点在于：
Q． 讉KEJB属性时增加了额外的操作。需要通过关键字映属性，最后还需q行cd转换?BR>Q． 需要徏立客L(fng)与服务器端的命名U定?
Q． 因ؓ通过HashMap操作时候需要进行类型{换，Ҏ(gu)产生q行时类型不匚w异常?/P>
Business Interface
EJB规范要求Bean实现cdd现所有在q程Q或本地Q接口中定义的所有方法，同时不允许Bean实现cȝ接承远E（或本圎ͼ接口。这导致编译时候很Ҏ(gu)产生两者不一致的问题Q即q程Q或本地Q接口中定义的某Ҏ(gu)为在Bean实现cM被实现等错误。ؓ避免上诉错误Q可以利用应用服务器厂商所提供的工兗但也可以应用EJB的设计架构来实现Q定义商业接口?BR>Business Interface卛_定义商业接口Q在接口中定义所有EJB提供的商业方法，q让Bean实现cdq程Q或本地Q接口都实现该商业接口。其l承关系见下图９Q?BR>
图９Q商业接口的使用
Business Interface是个普通的Java Class。依赖于使用本地接口与远E接口的不通，Business Interface的定义略有不同：应用与远E接口时Q在接口中的Ҏ(gu)需要抛出java.rmi.RemoteExceptionQ而应用与本地接口时候则不需要作M特别处理?BR>应用Business Interface时候必L意一点：EJB规范不允许直接EJB的实例将对自q引用Qthis对象Q返回给客户端，否则~译时候即报错。但使用Business Interface后，~译时候无法检查出有无this对象q回l客L(fng)。这一炚w要程序员自己保证?/P>
三． 内部数据转换{略
Data Transfer Object
ZEJB的J2EE多层架构应用中，l常涉及的一个问题就是如何在各层之间传递批量数据，比如客户端对服务器端数据的批量读写操作等。比如需要得到实体EJB的属性，直接的方法是多次调用不通的属性，如下图１Q：
图１Q：低效的数据传递方?BR> 但这U方法容易导致许多问题，比如性能以及代码的复杂度{，更有效的办法是在一个调用中得到所有需要的属性。所以可以引入Data Transfer Object来封装所需要的属性，q在客户与服务器端通过传递该对象一ơ实现对数据的操作。如下图Q１Q?BR>
图１Q：通过DTO传递数?BR>
DTO为普通的Java ClassQ通常是服务器端数据的快照。由于网l传输的需要，DTO应该实现java.io.Serializable接口?BR>DTO的设计有两种模型QDomain DTO以及Custom DTO?BR>Domain DTO仅仅实现Ҏ(gu)务器数据的拷贝，通常与实体EJBZ对一的关p?也存在ؓ多个相关联的实体EJB对应一个Domain DTO)。Domain DTO通常除用于读取更改实体EJB属性外也可用于创徏实体EJB时候。实体EJB与Domain DTO对应关系如下图１Q：
图１Q：Account EJB 与 Account DomainDTO
Domain DTO的应用除了DTO所h的一般优点外Q还有别的益处：
Q． 开发迅速。因Z旦实体EJB设计好后Q很Ҏ(gu)转换得到Domain DTO?BR>Q． 可以利用Domain DTO的setXXX()Ҏ(gu)在客L(fng)q行属性有效性效验?BR>Domain DTO的缺Ҏ(gu)Q?BR>Q． 客户端绑定了服务器端数据模型Q不利于l护?BR>Q． 不够灉|Q无法处理客L(fng)的多样化数据要求。对一个数百个属性的实体EJBh一个属性时候却q回一个包含所有属性值的Domain DTO明显是笨重的实现?BR>Q． D代码的重复?BR>Q． Domain DTO中如果嵌套包含了别的Domain DTOӞ一旦需服务器端数据的更改而需要重定义Domain DTO模型时候异常困难?/P>
Custom DTO则可以克服上q的一些缺炏VCustomer DTO仅仅装用户感兴的服务器数据集卛_以根据客L(fng)需求创建Customer DTO。这样作的优Ҏ(gu)灉|高效Q缺Ҏ(gu)大项目中可能D大量的Customer DTO存在?BR>通常Domain DTO可以用于数据的更C创徏QCustomer DTO可以用于客户用于表现层的数据d。两者可以相辅相成。而且使用DTO一般与DTO Factory同时使用?/P>
Domain Transfer Hash Map
DTO的用往往~Z通用性。不通的用户案例需要创Z同的DTO。当目很复杂时Q从l护性考虑需要更好的数据传输的实现方式?
Domain Transfer Hash Map卛_用HashMap作ؓ客户所需数据集的装。好处是Q?BR>Q． 良好的维护性?BR>Q． 较大的通用性。不同的客户端可以用相同的数据传递方式?BR>~点是：
Q． 需要维护客L(fng)与服务器端在属性及其对应关键字的映关pR?BR>Q． 当需要用基本类型的数据时候，因ؓHash Map的限制必d基本cd先{换成对象?BR>Q． 使用得到的数据时Q需要进行类型强制{换?/P>
Data Transfer RowSet
当需要处理直接的JDBC调用得到的结果集Ӟ昄用DTO/Hash Map已经不合适，因ؓ需要对大量数据q行cd转换{额外操作是很费资源和不必要的，而且最l用户常需要以表格式样昄数据?
所以对二维表式数据Q更好的处理方式是利用Data Transfer RowSet。Data Transfer RowSet通过ResultSet直接转换为RowSet传递给客户端?BR>在Session EJB中用RowSet的一D늤例代码如下图Q３Q?BR>
图１Q：使用RowSet
使用RowSet的好处很多：
Q． 接口通用于各L(fng)数据库查询操作?BR>Q． 当需要表格式数据昄Ӟ因ؓ直接从ResultSet得到Q所以不需要额外的数据cd转换?BR>~点是：
Q． 数据库结构暴露给客户端?BR>Q． 不符合面向对象设计思想?BR>Q． 依赖于SQL?BR>Data Transfer RowSet通常用于只读式数据的昄操作Q经常和JDBC for Reading Patternq用?/P>
四．事务和数据持久机?/P>
JDBC for Reading Pattern
ZEJB的J2EE应用中，通过EJBҎ(gu)据库的操作可以有两种方式Q实体EJB或者Session EJB中直接利用JDBC讉K?BR>客户很多时候取出数据库中数据ƈ以表格方式显C。这U情形如果用实体EJB会导致如下问题：
Q． 引用服务器端频繁的数据库查询和加载操作。因为加载N个实体EJB总需要进行一ơfind()操作 Nơ数据加载?BR>Q． 如果使用Remote接口Q引起频J的额外|络操作?BR>Q． 对关联关pL较复杂的数据库表l构Q很隄接通过Entity EJB表现?BR>因此在只需Ҏ(gu)据库表数据进行只读访问时候，应该采用JDBC for Reading PatternQ即通过JDBC直接讉K数据库。除了避免上qC用实体EJB的缺点还带来一下好处：
Q． 充分利用数据库能力，比如数据库的~存机制?BR>Q． 减少了对事务控制的资源?BR>Q． 利用自定义SQL可以按需要比较灵zȝd数据?BR>Q． 只需要一ơ数据查询，减少了数据库操作?BR>~点是：
Q． 于J2EE应用的面向对象设计相q背?BR>Q． 因ؓSession EJB代码中包含了自定义SQLQ维护性差?BR>Q． Session EJB中不得不包含JDBC的APIQƈ且需要了解数据库l构?/P>
]]>