毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。

　　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 {
　　 protected catalogdao dao;

　　//从dao工厂中获取一个dao 这是调用工厂(factory)模式的一个实例
　　 public void ejbcreate() {
　　　　 try {
　　　　　　 dao = catalogdaofactory.getdao();
　　　　 }
　　　　 catch (catalogdaosysexception se) {
　　　　　　 debug.println("exception getting dao " + se);
　　　　　　 throw new ejbexception(se.getmessage());
　　　　 }
　　 }

　　....

　}

　　我们发现在catalogejb中并没有通常的会话bean那样有对数据库操作的"select .. from ."等之类sql操作语句，这些都被封装到dao的具体实现中(concrete class).

　　在catalog这个示例中使用了设计模式的bridge模式,判断是否是某种模式，主要依据其参与者的种类和相互关系，我们先看看bridge模式的定义和参与者：（未完待续）