与数据库连接释放有关的设计模式
使用Java做过商业应用开发的人想必一定用到过数据库。
不论具体方案是使用JDBC还是JDO还是直接使用J2EE提供的连接池又或者是使用Hibernate屏蔽了这一切，不变的原则是，数据库连接是有限的资源，为了实现数据持久化的高效和稳定，不应该不加控制地频繁创建数据库连接；更不能在建立连接（或从连接池中取出）并使用之后就简单地结束，而不做资源回收。即使这种资源有超时空闲的自动回收机制，这种做法也是不可接受的。
打住，随便发了点儿评论。言归正传，本文的标题虽然是讨论数据库连接释放的问题，但实质是借着这个话题说明一下设计模式在Java中的应用。
现在，让我们设想一个虚拟场景：当前项目的数据库连接方式采用了JDBC + 连接池。如此设想是因为大概这种实现的效率最高，且可以发挥的地方也最多。
系统启动阶段建立了数据库的连接池，里面预先放了很多的连接，供需要持久化的模块调用，并接收返还的连接。
这里，每块借用了连接的代码都要记得用完了之后一定得返还连接。否则，连接池里的连接用完了，系统就不得不新建连接，迟早会抛出连接无法创建的异常。
那么，第一种方案是，把所有的数据库操作放在一个try块里。然后在finally里执行返还连接的操作。这种方案好处是便于实现，目的单纯。对于只有一、两处数据库操作的应用来说，效果明显，维护起来也不困难。
但是假设应用中不只含有一个数据库，比如说是按照功能划分了安全管理、商品库存、销售记录、员工考勤等库（表空间），而实际上会用到数据操作的不下几十处，那么第一种方案就是有问题的了。尤其对于一次访问若干个库，比如说同时访问商品库存和销售记录，同时访问安全管理和员工考勤，这时候程序员要时刻牢记目前有哪些连接在使用，finally要释放哪些连接，即使项目完成了，也不可能通过某种便捷有效的手段保证所有的连接都能够正常释放。举个最简单的例子。
当然，以上的代码只是符合某种数据库访问的需要，并不是普遍适用的例子。对于需要一边读入数据，一边更新表或者其它更为复杂模式的数据库使用，还是需要进一步改动作为引入参数的函数对象的设计和实现方式。这里就不进一步展开了。
OK，最后说一下我对其中有关的一些设计模式的理解。
首先，所谓命令模式，就是：
我接编程项目，这是一个抽象概念。所有的编程项目都是一样的需求文档格式，一样的产品输出介质，这是统一的接口。你需要实现一个Java项目，这是一个具体的请求。于是，我雇了一个小伙计，帮你把项目做了。你把钱给我。这是一个用例。
如此，虽然我对外接收编程项目，但实质工作不是我做的，我把工作转嫁给别人去做。
我只不过规范了编程人员的需求输入和产品输出。并通过这个接口派发项目。
至于编程人员怎么开发，我也不知道。
我们的例子中，小伙计使用的需求文档格式就是DbParamInjector，如果有输出的话，处理输出的就是DbReader。
其次，所谓工厂模式，就是：
咖啡厂制造罐装咖啡。一罐咖啡包含咖啡粉、植脂末、糖、添加剂、瓶子，包装纸。装瓶的流程是确定的，原料还没到。一旦原料定下来了，咖啡的风味就定了。那么就先安排好工位，大家排排坐。原料来了，一罐罐咖啡也出来了。
而我们的例子里面，就多了最后一步，把用剩下的咖啡粉扫扫起来，倒入原料池。
