什么是设计模式
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、 代码 设计经验的总结。使用设计模式是为了可重用 代码 、让 代码 更容易被他人理解、保证 代码 可靠性。
毫无疑问,设计模式于己于他人于 系统 都是多赢的,设计模式使 代码 编制真正工程化,设计模式是 软件 工程的基石,如同大厦的一块块砖石一样。
GoF的“设计模式”是第一次将设计模式提升到理论高度,并将之规范化,本书提出了23种基本设计模式,自此,在可复用面向对象 软件 的发展过程中,新的大量的设计模式不断出现。
设计模式和框架
现在,可复用面向对象 软件 系统 现在一般划分为三大类:应用 程序 工具 箱和框架(Framework),我们平时 开发 的具体 软件 都是应用 程序 ; Java 的API属于 工具 箱;而框架是构成一类特定 软件 可复用设计的一组相互协作的类。EJB(Enterprise Java Beans)是 Java 应用于企业计算的框架.
框架通常定义了应用体系的整体结构类和对象的关系等等设计参数,以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录 软件 应用中共同的设计决策,框架强调设计复用,因此框架设计中必然要使用设计模式.
另外,设计模式有助于对框架结构的理解,成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式,毫无疑问,你将迅速掌握框架的结构,我们一般 开发 者如果突然接触EJBJ2EE等框架,会觉得特别难学,难掌握,那么转而先掌握设计模式,无疑是给了你剖析EJB或J2EE 系统 的一把利器。
EJB中的设计模式
下面我们从设计模式的角度看看EJB的框架是怎样的?在这之前假设你已经大概了解了设计模式。专门的设计模式阐述请见我的设计模式之系列.
EJB是采取多层结构,原先我们 数据库 开发 基本是应用 程序 (商业逻辑运算)直接调用 数据库 驱动,在EJB中,为将商业逻辑计算和 数据库 截然分开,使用多个结构式模式:Adapter模式和Bridge模式等.这样做的好处显然有三个:
1.分离了商业逻辑层和数据访问层;
2.能同时支持多个 数据库 ;
3.但 数据库 类型更换时,不会设计到商业逻辑 代码 的大量修改.
EJB中将对 数据库 进行调用(如发出select等语句)称为会话bean(Sessionbean),而将对应 数据库 一个个记录的bean称为实体bean(Entitybean);由这两种类型的bean完成对 数据库 的访问.
会话bean一般和客户端应用是一一对应,而和 数据库 端联系紧密的是实体bean,EJB在实体bean(或直接在会话bean)和 数据库 之间使用了Adapter模式和Bridge模式,无意在实体bean和 数据库 之间又多了一层,称之为DAO(DataAccessObject),DAO实际就是设计模式的混合体.
我们以 Java 的宠物店中的Catalog为例,这是专门处理宠物店中的宠物类别,在对 数据库 访问中,有两个主要 程序 :CatalogEJB和CatalogDAO,我们从具体 代码 中看看设计模式是怎么应用的.
Bridge模式和Adapter模式
我们首先看看CatalogEJB 代码 :
publicclassCatalogEJBimplementsSessionBean{
protectedCatalogDAOdao;
//从DAO工厂中获取一个DAO这是调用工厂(factory)模式的一个实例
publicvoidejbCreate(){
try{
dao=CatalogDAOFactory.getDAO();
}
catch(CatalogDAOSysExceptionse){
Debug.println("Exceptiongettingdao"+se);
thrownewEJBException(se.getMessage());
}
}
....
}
我们发现在CatalogEJB中并没有通常的会话bean那样有对 数据库 操作的"select..from."等之类SQL操作语句,这些都被封装到DAO的具体实现中(Concreteclass).
在Catalog这个示例中使用了设计模式的Bridge模式,判断是否是某种模式,主要依据其参与者的种类和相互关系,我们先看看Bridge模式的定义和参与者:
Bridge模式是将抽象和行为划分开来,各自独立,但能动态的结合起来(好象搭建了一座桥)。在本例中,是将商业逻辑和 数据库 访问这样的行为划分开来, 数据库 访问专门放置在DAO中了。
Bridge模式需要两个接口(抽象类和接口通称为接口),一个用来封装抽象部分,本例中是封装商业逻辑,是CatalogEJB;还有一个是封装行为(Implementor),本例中是CatalogDAO,看看CatalogDAO 代码 :
publicinterfaceCatalogDAO{
publicCategorygetCategory(StringcategoryID,Localel)
throwsCatalogDAOSysException;
publicPagegetCategories(intstart,intcount,Localel)
throwsCatalogDAOSysException;
publicProductgetProduct(StringproductID,Localel)
throwsCatalogDAOSysException;
publicPagegetProducts(StringcategoryID,intstart,intcount,Localel)
throwsCatalogDAOSysException;
publicItemgetItem(StringitemID,Localel)
throwsCatalogDAOSysException;
publicPagegetItems(StringproductID,intstart,intsize,Localel)
throwsCatalogDAOSysException;
publicPagesearchItems(Stringquery,intstart,intsize,Localel)
throwsCatalogDAOSysException;
}
Bridge模式中参与者还需要有行为接口的具体实现(ConcreteImplementor),在本例中是CatalogDAOImpl,虽然在目前宠物店中只有一个ConcreteImplementor,但是可扩展为到MysqlXML等数据源访问,比如你可以自己新增一个叫CatalogDAOImplMysql,也是作为CatalogDAO的子类。
看看CatalogDAO的一个子类CatalogDAOImpl的 代码 :
publicclassCatalogDAOImplimplementsCatalogDAO{
protectedstaticDataSourcegetDataSource()
throwsCatalogDAOSysException{
try{
InitialContextic=newInitialContext();
return(DataSource)ic.lookup(JNDINames.CATALOG_DATASOURCE);
}
catch(NamingExceptionne){
thrownewCatalogDAOSysException("NamingExceptionwhilelooking"
+"upDBcontext:"
+ne.getMessage());
}
}
//具体Select语句在这里出现,这里主要是Oracle 数据库 的访问语句
publicCategorygetCategory(StringcategoryID,Localel)
throwsCatalogDAOSysException{
Connectionc=null;
PreparedStatementps=null;
ResultSetrs=null;
Categoryret=null;
try{
c=getDataSource().getConnection();
ps=c.prepareStatement("selecta.catid,name,descn"
+"from(categoryajoin"
+"category_detailsbon"
+"a.catid=b.catid)"
+"wherelocale=?"
+"anda.catid=?",
ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ps.setString(1,l.toString());
ps.setString(2,categoryID);
rs=ps.executeQuery();
if(rs.first()){
ret=newCategory(rs.getString(1).trim(),
rs.getString(2),
rs.getString(3));
}
rs.close();
ps.close();
c.close();
returnret;
}
catch(SQLExceptionse){
thrownewCatalogDAOSysException("SQLException:"
+se.getMessage());
}
....
}
Bridge模式参与者总结如下:
商业逻辑抽象类(CatalogEJB)
抽象的商业逻辑操作.
对DAOImplementor调用.
不关心是具体什么数据源被使用(无论是Oracle还是JDBC还是XML).
DAO(DataAccessObject)(CatalogDAO)
对数据源的抽象操作行为.
提供了非常方便访问和维护 管理 数据的API结构.
DAOImplementor(CatalogDAOImpl有可能有CatalogDAOImplSybaseCatalogDAOImplMysql等)
实现具体的DAO接口 内容 .
使用Adapter模式,将特定的数据源驱动接口适配到DAO接口中去
数据源(Oracle,orSybasedatabaseviaJDBCAPI)
提供访问具体 数据库 的驱动接口,如包括连接池等.
在使用数据源驱动接口时,需要使用Adapter模式,Adapter模式将两个不相关的类纠合在一起使用,Adapter模式实际是使用组合(composition)和继承(inheritance)两种方式再生类,在著名的"thinkin Java "的"类再生"专门提到这两个方式.
很显然,如果你对Bridge模式和Adapter模式熟悉,那么对宠物店中的Catalog理解就会非常快,同样,在宠物店其他部分如订单用户注册等都能迅速理解。
Factory模式和Singleton模式
该模式类似new,是用来创建对象的,使用Factory模式是为了实现面向对象的基本原则.封装(Encapsulation)和分派(Delegation);将创建对象与使用对象进行分工。因此在平时 开发 过程中,尽量使用Factory模式创建对象。
本例CatalogEJB中是使用Factory模式获得一个DAO的具体实例对象,见上面CatalogEJB 代码 中注释。我们看看CatalogDAOFactory的 代码 :
publicclassCatalogDAOFactory{
publicstaticCatalogDAOgetDAO()throwsCatalogDAOSysException{
CatalogDAOcatDao=null;
try{
InitialContextic=newInitialContext();
StringclassName=(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao=(CatalogDAO)Class.forName(className).newInstance();
}catch(NamingExceptionne){
...
}
returncatDao;
}
在CatalogDAOFactory可以依据 系统 的配置文件,动态获得DAO的方法,之所以采取动态方式,当然便于用户自己增加自己的DAO方式,而不必修改 代码 ,只要直接修改配置文件就可以。
如果在这里只需要CatalogDAOFactory产生一个实例,可以采取Singleton模式,Singleton的目的是控制类实例对象的创建,并且允许整个 程序 只在一点对它进行访问。Singleton本身类只能创建一个,是单线程。
publicclassCatalogDAOFactory{
privatestaticCatalogDAOcatDao=null;
publicstaticCatalogDAOgetIntance(){
if(catDao==null)
try{
InitialContextic=newInitialContext();
StringclassName=
(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao=(CatalogDAO)Class.forName(className).newInstance();
}catch(NamingExceptionne){
...
}
}
returncatDao;
}
}
那么在CatalogEJB的调用从
dao=CatalogDAOFactory.getDAO();
要改为
dao=CatalogDAOFactory.getIntance();
Facade模式
在EJB应用中,有两个端点,这一端是用户端,另外一端是EJB,通常在这两个端点间会增加一层,用来松散两个端点之间的耦合,比如在宠物店例子中,考虑到不同身份的用户有不同的操作流程,比如顾客注册进入后,需要浏览目录,下订单,而商店 管理 者进入后需要确认或者否定订单,或者检查库存。这些功能需要借助Sessionbean和Entitybean完成。
但是如果用户端直接和这些bean互动,会有以下问题:
1.用户端必须注意和这些beans的所有有联系或互动的事情,无法阻止用户端可能不恰当的使用这些beans.
2.如果EJB的API改动,那么用户端的一些 代码 也要修改。无疑扩展性很差。
3.即使这些beans都在同一台服务器上,用户端还是用remote方式来调用它们,造成 网络 无故拥挤。
那么我们使用Facade模式来解决这个问题,Facade的定义是为子 系统 中的一组接口提供一个一致的界面,很显然我们需要为这些bean提供一个统一的对外界面。如下图:
在宠物店中,ShoppingClientFacadeLocalEJB是面对所有用户端操作的统一界面,用户端操作就不直接和那些EJB如CustomerEJB或ShoppingCartEJB有联系,而是都通过ShoppingClientFacadeLocalEJB来联系的。 代码 如下:
publicclassShoppingClientFacadeLocalEJBimplementsSessionBean{
...
//和CustomerEJB联系
publicCustomerLocalgetCustomer()throwsFinderException{
if(userId==null){
...
}
try{
InitialContextic=newInitialContext();
Objecto=ic.lookup(" java :comp/env/ejb/petstore/local/customer");
CustomerLocalHomehome=(CustomerLocalHome)o;
customer=home.findByPrimaryKey(userId);
}catch( java x.naming.NamingExceptionnx){
...
}
returncustomer;
}
.....
//和ShoppingCartEJB联系
publicShoppingCartLocalgetShoppingCart(){
if(cart==null){
try{
InitialContextic=newInitialContext();
Objecto=ic.lookup(" java :comp/env/ejb/cart/Cart");
ShoppingCartLocalHomehome=(ShoppingCartLocalHome)o;
cart=home.create();
}catch( java x.ejb.CreateExceptioncx){
...
}
}
returncart;
}
....
}
Facade模式参与者:
SessionFacade(ShoppingClientFacadeLocalEJB)
提供一组操作流程
将真正工作委托到EJB的bean.
EJB的bean(CustomerEJB,ShoppingCartEJB等等)
执行基本的商业逻辑操作
没有任何对SessionFacade的调用.
这样不但可扩展性大大增强,效率也提高了,用户端只需要一次Remote对SessionFacade调用就可以了,而SessionFacade会自动定位到与它同一台服务器的那些邻居bean(CustomerEJB,ShoppingCartEJB等等),无疑减少 网络 拥挤,提高了速度.
总结
在EJB的具体使用中,使用合适的设计模式,不但使 代码 可重用性可拓展性增强,最重要的是能提高效率和速度,我们知道EJB框架由于考虑大型 系统 中事务安全等各方面问题,效率性能有所欠缺,那么我们在具体问题具体应用时,使用设计模式可以弥补这个问题。
例如Proxy模式可以为我们在访问巨大的需要花费一定时间才能展开的对象时,提供一个代理,这样不会因为那个巨大对象而影响当前运行速度,EJB中的那些bean很显然属于巨大对象(因为它们有反复的 数据库 操作,这些很费时间〕。
Flyweight模式是避免大量拥有相同 内容 的小类的开销(如耗费 内存 ),使大家共享一个类(元类).当你要从EJB中获取一系列字符串,而这些字符串中肯定有许多是重复的,那么我们可以将这些重复的字符串储存在Flyweight池(pool)中以达到共享
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、 代码 设计经验的总结。使用设计模式是为了可重用 代码 、让 代码 更容易被他人理解、保证 代码 可靠性。
毫无疑问,设计模式于己于他人于 系统 都是多赢的,设计模式使 代码 编制真正工程化,设计模式是 软件 工程的基石,如同大厦的一块块砖石一样。
GoF的“设计模式”是第一次将设计模式提升到理论高度,并将之规范化,本书提出了23种基本设计模式,自此,在可复用面向对象 软件 的发展过程中,新的大量的设计模式不断出现。
设计模式和框架
现在,可复用面向对象 软件 系统 现在一般划分为三大类:应用 程序 工具 箱和框架(Framework),我们平时 开发 的具体 软件 都是应用 程序 ; Java 的API属于 工具 箱;而框架是构成一类特定 软件 可复用设计的一组相互协作的类。EJB(Enterprise Java Beans)是 Java 应用于企业计算的框架.
框架通常定义了应用体系的整体结构类和对象的关系等等设计参数,以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录 软件 应用中共同的设计决策,框架强调设计复用,因此框架设计中必然要使用设计模式.
另外,设计模式有助于对框架结构的理解,成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式,毫无疑问,你将迅速掌握框架的结构,我们一般 开发 者如果突然接触EJBJ2EE等框架,会觉得特别难学,难掌握,那么转而先掌握设计模式,无疑是给了你剖析EJB或J2EE 系统 的一把利器。
EJB中的设计模式
下面我们从设计模式的角度看看EJB的框架是怎样的?在这之前假设你已经大概了解了设计模式。专门的设计模式阐述请见我的设计模式之系列.
EJB是采取多层结构,原先我们 数据库 开发 基本是应用 程序 (商业逻辑运算)直接调用 数据库 驱动,在EJB中,为将商业逻辑计算和 数据库 截然分开,使用多个结构式模式:Adapter模式和Bridge模式等.这样做的好处显然有三个:
1.分离了商业逻辑层和数据访问层;
2.能同时支持多个 数据库 ;
3.但 数据库 类型更换时,不会设计到商业逻辑 代码 的大量修改.
EJB中将对 数据库 进行调用(如发出select等语句)称为会话bean(Sessionbean),而将对应 数据库 一个个记录的bean称为实体bean(Entitybean);由这两种类型的bean完成对 数据库 的访问.
会话bean一般和客户端应用是一一对应,而和 数据库 端联系紧密的是实体bean,EJB在实体bean(或直接在会话bean)和 数据库 之间使用了Adapter模式和Bridge模式,无意在实体bean和 数据库 之间又多了一层,称之为DAO(DataAccessObject),DAO实际就是设计模式的混合体.
我们以 Java 的宠物店中的Catalog为例,这是专门处理宠物店中的宠物类别,在对 数据库 访问中,有两个主要 程序 :CatalogEJB和CatalogDAO,我们从具体 代码 中看看设计模式是怎么应用的.
Bridge模式和Adapter模式
我们首先看看CatalogEJB 代码 :
publicclassCatalogEJBimplementsSessionBean{
protectedCatalogDAOdao;
//从DAO工厂中获取一个DAO这是调用工厂(factory)模式的一个实例
publicvoidejbCreate(){
try{
dao=CatalogDAOFactory.getDAO();
}
catch(CatalogDAOSysExceptionse){
Debug.println("Exceptiongettingdao"+se);
thrownewEJBException(se.getMessage());
}
}
....
}
我们发现在CatalogEJB中并没有通常的会话bean那样有对 数据库 操作的"select..from."等之类SQL操作语句,这些都被封装到DAO的具体实现中(Concreteclass).
在Catalog这个示例中使用了设计模式的Bridge模式,判断是否是某种模式,主要依据其参与者的种类和相互关系,我们先看看Bridge模式的定义和参与者:
Bridge模式是将抽象和行为划分开来,各自独立,但能动态的结合起来(好象搭建了一座桥)。在本例中,是将商业逻辑和 数据库 访问这样的行为划分开来, 数据库 访问专门放置在DAO中了。
Bridge模式需要两个接口(抽象类和接口通称为接口),一个用来封装抽象部分,本例中是封装商业逻辑,是CatalogEJB;还有一个是封装行为(Implementor),本例中是CatalogDAO,看看CatalogDAO 代码 :
publicinterfaceCatalogDAO{
publicCategorygetCategory(StringcategoryID,Localel)
throwsCatalogDAOSysException;
publicPagegetCategories(intstart,intcount,Localel)
throwsCatalogDAOSysException;
publicProductgetProduct(StringproductID,Localel)
throwsCatalogDAOSysException;
publicPagegetProducts(StringcategoryID,intstart,intcount,Localel)
throwsCatalogDAOSysException;
publicItemgetItem(StringitemID,Localel)
throwsCatalogDAOSysException;
publicPagegetItems(StringproductID,intstart,intsize,Localel)
throwsCatalogDAOSysException;
publicPagesearchItems(Stringquery,intstart,intsize,Localel)
throwsCatalogDAOSysException;
}
Bridge模式中参与者还需要有行为接口的具体实现(ConcreteImplementor),在本例中是CatalogDAOImpl,虽然在目前宠物店中只有一个ConcreteImplementor,但是可扩展为到MysqlXML等数据源访问,比如你可以自己新增一个叫CatalogDAOImplMysql,也是作为CatalogDAO的子类。
看看CatalogDAO的一个子类CatalogDAOImpl的 代码 :
publicclassCatalogDAOImplimplementsCatalogDAO{
protectedstaticDataSourcegetDataSource()
throwsCatalogDAOSysException{
try{
InitialContextic=newInitialContext();
return(DataSource)ic.lookup(JNDINames.CATALOG_DATASOURCE);
}
catch(NamingExceptionne){
thrownewCatalogDAOSysException("NamingExceptionwhilelooking"
+"upDBcontext:"
+ne.getMessage());
}
}
//具体Select语句在这里出现,这里主要是Oracle 数据库 的访问语句
publicCategorygetCategory(StringcategoryID,Localel)
throwsCatalogDAOSysException{
Connectionc=null;
PreparedStatementps=null;
ResultSetrs=null;
Categoryret=null;
try{
c=getDataSource().getConnection();
ps=c.prepareStatement("selecta.catid,name,descn"
+"from(categoryajoin"
+"category_detailsbon"
+"a.catid=b.catid)"
+"wherelocale=?"
+"anda.catid=?",
ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ps.setString(1,l.toString());
ps.setString(2,categoryID);
rs=ps.executeQuery();
if(rs.first()){
ret=newCategory(rs.getString(1).trim(),
rs.getString(2),
rs.getString(3));
}
rs.close();
ps.close();
c.close();
returnret;
}
catch(SQLExceptionse){
thrownewCatalogDAOSysException("SQLException:"
+se.getMessage());
}
....
}
Bridge模式参与者总结如下:
商业逻辑抽象类(CatalogEJB)
抽象的商业逻辑操作.
对DAOImplementor调用.
不关心是具体什么数据源被使用(无论是Oracle还是JDBC还是XML).
DAO(DataAccessObject)(CatalogDAO)
对数据源的抽象操作行为.
提供了非常方便访问和维护 管理 数据的API结构.
DAOImplementor(CatalogDAOImpl有可能有CatalogDAOImplSybaseCatalogDAOImplMysql等)
实现具体的DAO接口 内容 .
使用Adapter模式,将特定的数据源驱动接口适配到DAO接口中去
数据源(Oracle,orSybasedatabaseviaJDBCAPI)
提供访问具体 数据库 的驱动接口,如包括连接池等.
在使用数据源驱动接口时,需要使用Adapter模式,Adapter模式将两个不相关的类纠合在一起使用,Adapter模式实际是使用组合(composition)和继承(inheritance)两种方式再生类,在著名的"thinkin Java "的"类再生"专门提到这两个方式.
很显然,如果你对Bridge模式和Adapter模式熟悉,那么对宠物店中的Catalog理解就会非常快,同样,在宠物店其他部分如订单用户注册等都能迅速理解。
Factory模式和Singleton模式
该模式类似new,是用来创建对象的,使用Factory模式是为了实现面向对象的基本原则.封装(Encapsulation)和分派(Delegation);将创建对象与使用对象进行分工。因此在平时 开发 过程中,尽量使用Factory模式创建对象。
本例CatalogEJB中是使用Factory模式获得一个DAO的具体实例对象,见上面CatalogEJB 代码 中注释。我们看看CatalogDAOFactory的 代码 :
publicclassCatalogDAOFactory{
publicstaticCatalogDAOgetDAO()throwsCatalogDAOSysException{
CatalogDAOcatDao=null;
try{
InitialContextic=newInitialContext();
StringclassName=(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao=(CatalogDAO)Class.forName(className).newInstance();
}catch(NamingExceptionne){
...
}
returncatDao;
}
在CatalogDAOFactory可以依据 系统 的配置文件,动态获得DAO的方法,之所以采取动态方式,当然便于用户自己增加自己的DAO方式,而不必修改 代码 ,只要直接修改配置文件就可以。
如果在这里只需要CatalogDAOFactory产生一个实例,可以采取Singleton模式,Singleton的目的是控制类实例对象的创建,并且允许整个 程序 只在一点对它进行访问。Singleton本身类只能创建一个,是单线程。
publicclassCatalogDAOFactory{
privatestaticCatalogDAOcatDao=null;
publicstaticCatalogDAOgetIntance(){
if(catDao==null)
try{
InitialContextic=newInitialContext();
StringclassName=
(String)ic.lookup(JNDINames.CATALOG_DAO_CLASS);
catDao=(CatalogDAO)Class.forName(className).newInstance();
}catch(NamingExceptionne){
...
}
}
returncatDao;
}
}
那么在CatalogEJB的调用从
dao=CatalogDAOFactory.getDAO();
要改为
dao=CatalogDAOFactory.getIntance();
Facade模式
在EJB应用中,有两个端点,这一端是用户端,另外一端是EJB,通常在这两个端点间会增加一层,用来松散两个端点之间的耦合,比如在宠物店例子中,考虑到不同身份的用户有不同的操作流程,比如顾客注册进入后,需要浏览目录,下订单,而商店 管理 者进入后需要确认或者否定订单,或者检查库存。这些功能需要借助Sessionbean和Entitybean完成。
但是如果用户端直接和这些bean互动,会有以下问题:
1.用户端必须注意和这些beans的所有有联系或互动的事情,无法阻止用户端可能不恰当的使用这些beans.
2.如果EJB的API改动,那么用户端的一些 代码 也要修改。无疑扩展性很差。
3.即使这些beans都在同一台服务器上,用户端还是用remote方式来调用它们,造成 网络 无故拥挤。
那么我们使用Facade模式来解决这个问题,Facade的定义是为子 系统 中的一组接口提供一个一致的界面,很显然我们需要为这些bean提供一个统一的对外界面。如下图:
在宠物店中,ShoppingClientFacadeLocalEJB是面对所有用户端操作的统一界面,用户端操作就不直接和那些EJB如CustomerEJB或ShoppingCartEJB有联系,而是都通过ShoppingClientFacadeLocalEJB来联系的。 代码 如下:
publicclassShoppingClientFacadeLocalEJBimplementsSessionBean{
...
//和CustomerEJB联系
publicCustomerLocalgetCustomer()throwsFinderException{
if(userId==null){
...
}
try{
InitialContextic=newInitialContext();
Objecto=ic.lookup(" java :comp/env/ejb/petstore/local/customer");
CustomerLocalHomehome=(CustomerLocalHome)o;
customer=home.findByPrimaryKey(userId);
}catch( java x.naming.NamingExceptionnx){
...
}
returncustomer;
}
.....
//和ShoppingCartEJB联系
publicShoppingCartLocalgetShoppingCart(){
if(cart==null){
try{
InitialContextic=newInitialContext();
Objecto=ic.lookup(" java :comp/env/ejb/cart/Cart");
ShoppingCartLocalHomehome=(ShoppingCartLocalHome)o;
cart=home.create();
}catch( java x.ejb.CreateExceptioncx){
...
}
}
returncart;
}
....
}
Facade模式参与者:
SessionFacade(ShoppingClientFacadeLocalEJB)
提供一组操作流程
将真正工作委托到EJB的bean.
EJB的bean(CustomerEJB,ShoppingCartEJB等等)
执行基本的商业逻辑操作
没有任何对SessionFacade的调用.
这样不但可扩展性大大增强,效率也提高了,用户端只需要一次Remote对SessionFacade调用就可以了,而SessionFacade会自动定位到与它同一台服务器的那些邻居bean(CustomerEJB,ShoppingCartEJB等等),无疑减少 网络 拥挤,提高了速度.
总结
在EJB的具体使用中,使用合适的设计模式,不但使 代码 可重用性可拓展性增强,最重要的是能提高效率和速度,我们知道EJB框架由于考虑大型 系统 中事务安全等各方面问题,效率性能有所欠缺,那么我们在具体问题具体应用时,使用设计模式可以弥补这个问题。
例如Proxy模式可以为我们在访问巨大的需要花费一定时间才能展开的对象时,提供一个代理,这样不会因为那个巨大对象而影响当前运行速度,EJB中的那些bean很显然属于巨大对象(因为它们有反复的 数据库 操作,这些很费时间〕。
Flyweight模式是避免大量拥有相同 内容 的小类的开销(如耗费 内存 ),使大家共享一个类(元类).当你要从EJB中获取一系列字符串,而这些字符串中肯定有许多是重复的,那么我们可以将这些重复的字符串储存在Flyweight池(pool)中以达到共享