设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
gof的“设计模式”是第一次将设计模式提升到理论高度，并将之规范化，本书提出了23种基本设计模式，自此，在可复用面向对象软件的发展过程中，新的大量的设计模式不断出现。
设计模式和框架
现在，可复用面向对象软件系统现在一般划分为三大类：应用程序 工具箱和框架(framework),我们平时开发的具体软件都是应用程序；java的api属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作的类。ejb（enterprise javabeans）是java应用于企业计算的框架.
框架通常定义了应用体系的整体结构 类和对象的关系等等设计参数，以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策，框架强调设计复用，因此框架设计中必然要使用设计模式.
另外，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式，毫无疑问，你将迅速掌握框架的结构，我们一般开发者如果突然接触ejb j2ee等框架，会觉得特别难学，难掌握，那么转而先掌握设计模式，无疑是给了你剖析ejb或j2ee系统的一把利器。
ejb中的设计模式
下面我们从设计模式的角度看看ejb的框架是怎样的？在这之前假设你已经大概了解了设计模式。专门的设计模式阐述请见我的设计模式之系列.
ejb是采取多层结构，原先我们数据库开发基本是应用程序(商业逻辑运算)直接调用数据库驱动，在ejb中，为将商业逻辑计算和数据库截然分开，使用多个结构式模式:adapter模式和bridge模式等.这样做的好处显然有三个：
1.分离了商业逻辑层和数据访问层;
2.能同时支持多个数据库；
3.但数据库类型更换时，不会设计到商业逻辑代码的大量修改.
ejb中将对数据库进行调用(如发出select等语句)称为会话bean(sessionbean),而将对应数据库一个个记录的bean称为实体bean(entity bean);由这两种类型的bean完成对数据库的访问.
会话bean一般和客户端应用是一一对应，而和数据库端联系紧密的是实体bean,ejb在实体bean(或直接在会话bean)和数据库之间使用了adapter模式和bridge模式，无意在实体bean和数据库之间又多了一层，称之为dao(data access object )，dao实际就是设计模式的混合体.
我们以java的宠物店中的catalog为例,这是专门处理宠物店中的宠物类别,在对数据库访问中，有两个主要程序：catalogejb和catalogdao,我们从具体代码中看看设计模式是怎么应用的.
bridge模式和adapter模式
我们首先看看catalogejb代码：
public class catalogejb implements sessionbean { //从dao工厂中获取一个dao 这是调用工厂(factory)模式的一个实例 .... } |
我们发现在catalogejb中并没有通常的会话bean那样有对数据库操作的"select .. from ."等之类sql操作语句，这些都被封装到dao的具体实现中(concrete class).
在catalog这个示例中使用了设计模式的bridge模式,判断是否是某种模式，主要依据其参与者的种类和相互关系，我们先看看bridge模式的定义和参与者：
bridge模式是将抽象和行为划分开来,各自独立,但能动态的结合起来（好象搭建了一座桥）。在本例中，是将商业逻辑和数据库访问这样的行为划分开来，数据库访问专门放置在dao中了。
bridge模式需要两个接口(抽象类和接口通称为接口)，一个用来封装抽象部分，本例中是封装商业逻辑，是catalogejb;还有一个是封装行为(implementor)，本例中是catalogdao,看看catalogdao代码：
public interface catalogdao { public category getcategory(string categoryid, locale l) public page getcategories(int start, int count, locale l) public product getproduct(string productid, locale l) public page getproducts(string categoryid, int start, int count, locale l) public item getitem(string itemid, locale l) public page getitems(string productid, int start, int size, locale l) public page searchitems(string query, int start, int size, locale l)
|
bridge模式中参与者还需要有行为接口的具体实现(concreteimplementor),在本例中是catalogdaoimpl,虽然在目前宠物店中只有一个concreteimplementor,但是可扩展为到mysql xml等数据源访问,比如你可以自己新增一个叫catalogdaoimplmysql，也是作为catalogdao的子类。
看看catalogdao的一个子类catalogdaoimpl的代码：
public class catalogdaoimpl implements catalogdao { //具体select语句在这里出现，这里主要是oracle 数据库的访问语句 public category getcategory(string categoryid, locale l) connection c = null; try { ps = c.preparestatement("select a.catid, name, descn " c.close();
} |
bridge模式参与者总结如下：
商业逻辑抽象类 (catalogejb)
抽象的商业逻辑操作.
对daoimplementor调用.
不关心是具体什么数据源被使用(无论是oracle还是jdbc还是xml).
dao(data access object) (catalogdao)
对数据源的抽象操作行为.
提供了非常方便访问和维护管理数据的api结构.
daoimplementor (catalogdaoimpl 有可能有catalogdaoimplsybase catalogdaoimplmysql 等)
实现具体的dao接口内容.
使用adapter模式，将特定的数据源驱动接口适配到dao接口中去
数据源 ( oracle, or sybase database via jdbc api)
提供访问具体数据库的驱动接口，如包括连接池等.
在使用数据源驱动接口时，需要使用adapter模式，adapter模式将两个不相关的类纠合在一起使用，adapter模式实际是使用组合(composition)和继承(inheritance)两种方式再生类，在著名的"think in java"的"类再生"专门提到这两个方式.
很显然，如果你对bridge模式和adapter模式熟悉，那么对宠物店中的catalog理解就会非常快，同样，在宠物店其他部分如订单 用户注册 等都能迅速理解。
factory模式和singleton模式
该模式类似new，是用来创建对象的，使用factory模式是为了实现面向对象的基本原则.封装(encapsulation)和分派(delegation);将创建对象与使用对象进行分工。因此在平时开发过程中，尽量使用factory模式创建对象。
本例catalogejb中是使用factory模式获得一个dao的具体实例对象，见上面catalogejb代码中注释。我们看看catalogdaofactory的代码:
public class catalogdaofactory { catalogdao catdao = null; } |
在catalogdaofactory可以依据系统的配置文件，动态获得dao的方法，之所以采取动态方式，当然便于用户自己增加自己的dao方式，而不必修改代码，只要直接修改配置文件就可以。
如果在这里只需要catalogdaofactory产生一个实例,可以采取singleton模式,singleton的目的是控制类实例对象的创建，并且允许整个程序只在一点对它进行访问。singleton本身类只能创建一个,是单线程。
public class catalogdaofactory { public static catalogdao getintance(){ } } |
那么在catalogejb的调用从
dao = catalogdaofactory.getdao();
要改为
dao = catalogdaofactory.getintance();
facade模式
在ejb应用中，有两个端点，这一端是用户端，另外一端是ejb,通常在这两个端点间会增加一层，用来松散两个端点之间的耦合，比如在宠物店例子中,考虑到不同身份的用户有不同的操作流程，比如顾客注册进入后，需要浏览目录，下订单，而商店管理者进入后需要确认或者否定订单，或者检查库存。这些功能需要借助session bean和entity bean完成。
但是如果用户端直接和这些bean互动,会有以下问题:
1. 用户端必须注意和这些beans的所有有联系或互动的事情，无法阻止用户端可能不恰当的使用这些beans.
2.如果ejb的api改动，那么用户端的一些代码也要修改。无疑扩展性很差。
3.即使这些beans都在同一台服务器上，用户端还是用remote方式来调用它们，造成网络无故拥挤。
那么我们使用facade模式来解决这个问题，facade的定义是为子系统中的一组接口提供一个一致的界面,很显然我们需要为这些bean提供一个统一的对外界面。如下图：
在宠物店中，shoppingclientfacadelocalejb是面对所有用户端操作的统一界面，用户端操作就不直接和那些ejb如customerejb或shoppingcartejb有联系,而是都通过shoppingclientfacadelocalejb来联系的。代码如下：
public class shoppingclientfacadelocalejb implements sessionbean { //和customerejb联系 return customer; ..... //和shoppingcartejb联系 .... } |
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)中以达到共享。
在以后篇幅中会陆续介绍此类应用。
闽公网安备 35060202000074号