使用数据库连接池

如果不能从JNDI获取数据源，那么下一个选择应该是在Spring里直接配置一个数据源池。虽然Spring没有提供一个数据源池，但Jakarta Commons Database Connection Pools（DBCP）项目（http://jakarta.apache.org/commons/dbcp）提供了一个。为了把DBCP添加到程序，我们可以下载它并把JAR文件放到Ant的生成类路径里，或是把如下<dependency>添加到Maven 2 Project Object Model（POM）：

<dependency>
    <groupId>commons-dbcp</groupId>
    <artifactId>commons-dbcp</artifactId>
    <version>1.2.1</version>
</dependency>

DBCP包含多个提供池功能的数据源，BasicDataSource是最常用的一个，因为在Spring里配置它很容易，而且它类似于Spring自己的DriveManagerDataSource（稍后会有所介绍）。

对于RaodRantz程序，我们会像下面这样配置BasicDataSource Bean：

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName"  value="com.mysql.jdbc.Driver"></property>
    <property name="url" value="jdbc:mysql://localhost:3306/bank"></property>
    <property name="username" value="root"></property>
    <property name="password" value="123456"></property>
    <property name="initialSize" value="5"></property>
        <property name="maxActive" value="10"></property>
</bean>

前4个属性是配置BasicDataSource所必需的。driverClassName属性指定JDBC驱动类的完整修饰名称，在此我们把它配置为Hypersonic数据库的JDBC驱动。url属性用于设置数据库的完整JDBC URL。最后，username和password属性用于在连接到数据库时进行身份验证。

这4个基本属性定义了BasicDataSource的连接信息。另外，我们还可以使用其他一些属性来配置数据源池，表5.4列出了BasicDataSource中最有用的一些池配置属性。

表5.4 BasicDataSource的池配置属性

池配置属性	指定的内容
initialSize	池启动时创建的连接数量
maxActive	同一时间可以从池分配的最多连接数量。设置为0时表示无限制。
maxIdle	池里不会被释放的最多空闲连接数量。设置为0时表示无限制。
maxOpenPreparedStatements	同一时间能够从语句池里分配的已备语句的最大数量。 设置为0时表示无限制。
maxWait	在抛出异常之前，池等待连接被回收的最长时间 （当没有可用连接时）。设置为-1表示无限等待。
minEvictableIdleTimeMillis	连接保持空闲而不被驱逐的最长时间。
minIdle	在不新建连接的条件下，池中保持空闲的最少连接数。
poolPreparedStatements	是否对已备语句进行池管理（布尔值）。

在我们的范例里，池启动时有5个连接，在需要时可以新建连接，但最大连接数量为10。

       GoF《设计模式》中说到：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得客户对单个对象和组合对象的使用具有一致性。

       Composite组合模式结构如下：

       说道这，我觉得有一个编程中常见的场景，就是对于树的实现，很符合这个模式。下面我就用这个例子作一下。

       首先，我们先分析对于一棵树所包含的部分，树干、树枝、树叶，其中树干可以看成一个树枝（就是粗了点）。那么我们就应该有两种类实现Leaf（树叶）和Limb（树枝）。对于叶子节点和枝节点的不同在于枝节点有子树，而叶子节点没有子树。为了使单个对象和组合对象的使用具有一致性，我可以将叶子节点想象成没有子树的枝节点。这样我就可以得到一个抽象类，代码如下：

       public abstract class AbstractClass

    {

        public string name;

        public ArrayList list;

        public abstract void Add(AbstractClass item);       //增加一个子节点

        public abstract void Remove(AbstractClass item);    //去掉一个子节点

        public abstract string Print();                     //打印当前节点

    }

       然后，我在对叶子节点和枝节点作不同的实现：

       枝节点：

       public class Limb:AbstractClass

    {

        public Limb()

        {

            list = new ArrayList();

        }

        public override void Add(AbstractClass item)

        {

            list.Add(item);

        }

        public override void Remove(AbstractClass item)

        {

            if(list.Contains(item))

                list.Remove(item);

        }

        public override string Print()

        {

            Console.Write(name + "\n");

            if(list.Count != 0)

            {

                for(int i = 0;i<list.Count;i++)

                {

                    Console.Write("(Parent is " + name + ")");

                    ((AbstractClass)list[i]).Print();

                }

            }

            return name;

        }

    }

    叶子节点：

    public class Leaf:AbstractClass

    {

        public Leaf()

        {

            list = null;

        }

        public override void Add(AbstractClass item)

        {

        }

        public override void Remove(AbstractClass item)

        {

        }

        public override string Print()

        {

            Console.Write(name + ",");

            return this.name;

        }

    }

    对于叶子节点来说，不需要子节点，当然也就不需要添加和删除子节点的方法。

    好，接下来，我们可以在客户程序中组建一棵树，来测试一下：

        static void Main(string[] args)

        {

            AbstractClass Tree = new Limb();

            GetTree(Tree);

            PrintTree(Tree);

            Console.Read();

        }

        public static void GetTree(AbstractClass Tree)

        {

            Tree.name = "1";

            AbstractClass leaf2 = new Leaf();

            leaf2.name = "2";

            Tree.Add(leaf2);

            AbstractClass limb3 = new Limb();

            limb3.name = "3";

            Tree.Add(limb3);

            AbstractClass leaf4 = new Leaf();

            leaf4.name = "4";

            limb3.Add(leaf4);

            AbstractClass leaf5 = new Leaf();

            leaf5.name = "5";

            limb3.Add(leaf5);

        }

        public static void PrintTree(AbstractClass Tree)

        {

            Tree.Print();

        }

    输出结果如下：

1

(Parent is 1)2,(Parent is 1)3

(Parent is 3)4,(Parent is 3)5,

在组织这个树时，的确能感觉到GoF《设计模式》中的那句话：单个对象和组合对象的使用具有一致性。当然也的确感觉到一点矛盾：对于叶子节点来说，不需要ArrayList和Add（）Remove（）应该不继承才对，当然如果在代码执行性能可以达到要求的情况下，简化一下编码实现复杂度也是挺好的一件事。

最后在来说说Composite组合模式的几个要点：

       1、Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致的处理对象和对象容器，无需关心处理的是单个对象，还是组合的对象容器。

2、将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思想，解耦之后，客户代码将与纯粹的对象接口——而非对象容器的复杂内部实现结构——发生依赖关系，从而更能“应对变化”。

3、Composite模式中，是将“Add和Remove的和对象容器相关的方法”定义在“表示抽象对象的Component类”中，还是将其定义在“表示对象容器的Composite类”中，是一个关乎“透明性”和“安全性”的两难问题，需要仔细权衡结构，这又是必须付出的代价。

4、Composite模式在具体实现中，可以让父对象中的字对象反向追溯：如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率

       《设计模式》中说到将抽象部分与实现部分分离，使他们可以独立的变化。

       举个例子更清楚些，好像我们平时玩的游戏中有PS版的，但是不是大家都有PS。这时我们等一段时间，一般会出PC版的或其他版本。由于支持游戏的平台不一样，但是如果我们编写的游戏程序为了适应另一种平台就要全部重新编写的话岂不是很麻烦。再加上游戏本身的变动，一句众人皆知的话：“死定了”。

       现在我们来看看Bridge桥接模式，看看它是如何解决类似问题的，首先我们看看Bridge模式的结构。

       实际上，我们要做到的是把变化的部分提出，对其抽象，使变化独立。那我们如何做呢？通过组合的方式将变化独立出去。将一个事物中的多个纬度变化分离。

       下面举一个场景来理解一下，还是用汽车举例，我现在要一辆车（BMW或BORA）在路（WaterRoad或Cement）上跑。现在有两个纬度的变化点：汽车和路。也就是上图中的AbstractChangePoint1和AbstractChangePoint2。AbstractChangePoint1中包含有AbstractChangePoint2对象成员。。代码实现如下：

       abstract class AbstractCar

    {

        public AbstractRoad road;

        public AbstractCar(AbstractRoad road)

        {

            this.road = road;

        }

        public abstract string Run();

        public abstract string Stop();

    }

    abstract class AbstractRoad

    {

        public abstract string GetRoadType();

}

以汽车为变化中心，用组装的方式将两个变化点结合起来。使路的变化和汽车隔离。下面来编写路的实现。

class WaterRoad:AbstractRoad

    {

        public override string GetRoadType()

        {

            return "It is WaterRoad";

        }

 }

class CementRoad:AbstractRoad

    {

        public override string GetRoadType()

        {

            return "It is Cement";

        }

}

然后再来编写汽车的实现

class BMWCar:AbstractCar

    {

        public BMWCar(AbstractRoad road)

            : base(road)

        {

        }

        public override string Run()

        {

            return "BMW is running";

        }

        public override string Stop()

        {

            return "BMW is stopped";

        }

 }

class BROACar:AbstractCar

    {

        public BROACar(AbstractRoad road)

            : base(road)

        {

        }

        public override string Run()

        {

            return "BROA is running";

        }

        public override string Stop()

        {

            return "BROA is stopped";

        }

  }

然后我们在客户代码中调用这些类，首先，我想要这个场景是BMW在WaterRoad上跑，客户端代码如下：

static void Main(string[] args)

        {

            AbstractCar car = new BMWCar(new WaterRoad());

            Console.WriteLine(car.road.GetRoadType());

            Console.WriteLine(car.Run());

            Console.WriteLine(car.Stop());

            Console.Read();

        }

实现结果如下：

It is WaterRoad

BMW is running

BMW is stopped

如果我现在要一辆BORA在Cement上跑，我们只要稍微修改一下car的实例化就可以，代码如下：

static void Main(string[] args)

        {

            AbstractCar car = new BROACar(new CementRoad());

            Console.WriteLine(car.road.GetRoadType());

            Console.WriteLine(car.Run());

            Console.WriteLine(car.Stop());

            Console.Read();

     }

实现结果如下：

It is Cement

BROA is running

BROA is stopped

       最后我们再来说说Bridge模式的要点：

       1、Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的纬度来变化。

2、所谓抽象和实现沿着各自纬度的变化，即“子类化”它们，得到各个子类之后，便可以任意组合它们。

3、Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。

4、Bridge模式的应用一般在“两个非常强的变化纬度”，有时候即使有两个变化的纬度，但是某个方向的变化纬度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。