摘要:本文介绍了j2ee的分层结构,深入研究了如何使用session facade模式和valueobject 模式设计ejb，并对其开发过程做了较详细的说明。

　　关键字:ejb ;值对象模式;会话外观模式

　　一、概述

　　与传统的二层体系结构相比，j2ee有两个特点：

　　1、定义了一套标准化组件,通过为这些组件提供完整的服务。

　　2、使用多层分布式的应用程序模型。应用程序的逻辑根据其实现的不同功能被封装到不同的组件中。如图1所示。

　　这种多层结构使企业级应用具有很强的伸缩性,允许各层专注于某种特定的角色:

　　1、client tier用于显示。

　　2、web tier用于生成动态显示。

　　3、business tier用于实现业务逻辑。

　　4、eis tier用于数据库服务。

　　其中，用于实现业务逻辑的ejb组件架构是j2ee的基础和最重要的部分。

　　正是认识到j2ee平台作为一种可扩展的、全功能的平台，可以将关键的企业应用扩展到任何web浏览器上并可适合多种不同的internet数据流、可连接到几乎任何一种传统数据库和解决方案，j2ee已经成为开发电子商务应用的事实标准。

　　为了使开发者开发出规范的、可重用的应用程序，j2ee为我们提供了大量的模式。模式尽管有时不易理解，但使用却非常简单，它提供了强大的可重用机制，避免了开发者和设计者的重复投资。

　　可是，面对如此多的模式，初学者往往不知如何下手，为此，作者结合以往的开发经验，详细介绍如何使用模式完成ejb的设计。 二、设计与实现

　　1．值对象模式

　　j2ee应用程序把服务器端业务组件实现为会话bean和实体bean。对于实体bean的创建，开发人员通常采用cmp(容器管理持久性)模式，其好处在于容器提供公共的服务,例如目录服务、事务管理、安全性、持久性、资源缓冲池以及容错性等,使开发人员不必维护将会集成到业务逻辑中的系统级代码,只需专注于商业逻辑。

　　一般来说，有了实体bean，就可以通过调用业务组件的一些方法向客户端返回数据。初学者往往会认为既然客户端可以与服务器通信，那么任务就算完成了。可是，问题恰恰出在这里。业务组件的get方法只能返回一个属性值，这就导致需要获得所有属性值的客户端需要多次调用业务对象的get方法，如图2-1所示。每次调用都是一次网络调用,都会造成系统性能的退化,当调用次数增多时，系统性能就会严重下降。

　　这就要求有一种方法使客户端可以一次调用得到所需的大量数据，这种方法就是value object(值对象)模式。值对象是任意的可串行化的java对象，也被称为值的对象，它在一次网络传输中包含和封装了大量的数据并被保存在内存中。这样，当客户端需要再次使用数据的时候,不用再次到数据库中查询,而是直接在内存中读取值对象,节省了大量的时间和系统开销，如图2-2。

　　值对象模式有两种策略?d?d可更新的值对象策略和多值对象策略。

　　可更新的值对象策略中，业务对象负责创建值对象，并且在客户端请求时把该值对象返回给客户端；同时，业务对象也可以从客户端接收数据，形成值对象，并使用该对象来完成更新。

　　例如，在银行系统的例子中,account 中提供一个以accountvalue为参数的setaccountvalueobject方法，这样客户端可以通过这个方法来设置值对象的值，而不采用实体bean--account中设置每个属性的方法（setbalance()），因为后一种方法会导致大量的网络负载。由于值对象的易变性，所以值对象类必须给每个可以被客户端更新的属性提供设置方法。例如，accountvalue中的setbalance（）方法。这样，一旦某客户端拥有来自业务对象的值对象，客户端就可以在本地调用必要的设置方法来更改属性值，然后调用业务对象的setaccountvalueobject()方法更新业务对象。

　　多值对象策略

　　一些应用程序业务对象往往比较复杂，在这种情况下，根据客户端请求不同，有可能单个业务对象会产生多个不同的值对象。在这种情况下，可以考虑采用多值对象策略。这种策略的实现比较简单，就是在entity bean中增加不同的get×××valueobject（）方法和set×××valueobject()方法。

　　2．session facade 模式

　　有了实体bean，客户端就可以直接调用它以获得数据。也就是说实体bean封装了业务数据，并把他们的接口暴露给客户，因而也就把分布式服务的复杂性暴露给客户。在对j2ee 应用程序环境下，一般会产生如下问题：

　　1、紧密耦合，这回导致客户端和业务对象的直接依赖关系

　　2、客户端和服务器之间的网络方法调用太多，容易导致网络性能问题

　　3、缺乏统一的客户访问策略，容易误用业务对象

　　4、如果实体bean的api改动，那么用户端的一些代码也要修改，扩展性很差



　　解决这些问题的方法就是把客户端和实体bean分割开。本文采用session facade模式，如图3-2所示。该模式通过一个session bean，为一系列的实体bean提供统一的接口来实现流程。事实上，客户端只是使用这个接口来触发流程。这样，所有关于实体bean实现流程所需要的改变，都和客户端无关。当实体bean改变时,我们不用改变客户端的代码,只要对session bean做出相应的改变即可,大大提高了系统的可维护性。

　　通过实体bean来表示业务对象是session fa?ade的最常见用法。但多个实体bean参与某用例时，不必向客户暴露所有实体bean。相反的，用session bean 包装这些实体bean ,并且提供粗粒度方法来执行所需的业务功能，从而隐藏了实体bean交互的复杂性。

　　但是千万不要以为fa?ade模式就是简单的用session bean把entity bean的所有方法统统封装起来,而不提供任何额外的抽象。其实这是对fa?ade模式的滥用。这样做并不是降低整个系统的复杂性,而是把复杂性转移到另一个对象上。

　　正确应用facade模式应遵循三条基本原则:

　　1、他们自己不作实际工作,而是委派其他对象作实际工作。

　　2、他们提供简单的接口。

　　3、他们是底层系统的客户端接口。他们应该把特定于子系统的信息封装起来,并且不应该在不必要的情况下公开它。

三、具体代码

　　下面用一个简单的银行系统的例子来解释fa?ade模式和value object模式的具体应用。

　　创建entity bean。其中对每个属性的get和set方法是自动生成的，我们不去管它。

public interface account extends javax.ejb.ejbobject { private accountvalue creaeaccountvalueobject(); void setaccountvauleobject(accountvalue v); accountvalue getaccountvalueobject(); ……}

　　其中

private accountvalue createaccountvalueobject(){ accountvalue vo=new accountvalue(); vo. accountnumber=accountnumber; vo.balance=balance; ……} public accountvalue getaccountvalueobject(){ return createaccountvalueobject(); } public void setaccountvalueobject(accountvalue v){ accountnumber=v. accountnumber; balance=v.balance; ……}

　　用值对象封装entity bean数据。

public class accountvalue implements java.io.serializable { private java.lang.string accountnumber; private double balance; void setbalance(double newvalue) ……}

　　用factory或者是action类逻辑方法,涉及到数据的地方使用值对象。

public class accountfactory { 　private static accounthome accounthome = null; 　　…… 　public java.util.vector getaccounts(string userid) throws factoryexception { 　　try { vector vect = new vector(); 　　　accounthome home = getaccounthome(); 　　　enumeration accountrefs = home.findbyuserid(userid); 　　　while (accountrefs.hasmoreelements()) { 　　　　account acc = (account)accountrefs.nextelement(); 　　　　accountvalue valueobject =acc.getaccountvalueobjcet(); 　　　　vect.addelement(valueobject);} 　　　　return vect; } 　　……}

　　在session bean的get方法中调用factory或者是action对象。

public java.util.vector getaccounts(string userid) throws factoryexception { 　accountfactory fact = new accountfactory(); 　vector result = fact.getaccounts(userid); 　return result; }

　　正如代码所示,使用session facade模式，可以

　　1、提供统一的接口：会话外观抽象了业务组件交互的复杂性，并且向客户端提供一个更简单的接口。

　　2、减少耦合提高可管理性：会话外观分离了业务对象和客户端，这样可以减少紧密耦合，以及客户端对业务对象的依赖性。

　　3、提供粗粒度访问：会话外观减少客户端和服务器之间的网络负载。客户端与业务数据的说有交互都是通过会话外观以粗粒度的发拿过是进行的。

　　通过使用

　　从上述代码可以看出，使用模式之后，大大改善了系统性能，也提高了代码的可重用性。此外，开发者也可以采用其他的小模式来提高系统性能，比如服务器定位模式，在此不作进一步介绍。

　　四、总结

　　综上所述,本文详细地介绍了使用值对象模式和会话模式设计商业逻辑层的方法,很好的实现了数据封装和合理分层,大大提高了系统的可维护性和可伸缩性,也显著的简化了具有可伸缩性和高度负责的企业级应用的开发。

　　注：航天自然基金赞助支持