DataSource与DriverManager的比较

DriverManager

JDBC1.0

需要硬性编码驱动

不支持连接池

DataSource

JDBC2.0

无需硬性编码驱动

支持连接池

 

JDBC1.0使用DriverManager类来产生一个对数据源的连接，相对于DriverManager，JDBC2.0提供的DataSource接口是一个更好的连接数据源的方法。好处体现在以下两个方面：

1. 无需硬性编码驱动

一个DataSource对象代表了一个真正的数据源。根据DataSource的实现方法，数据源既可以是关系数据库，也可以是电子表格，还可以是一个表格形式的文件。当一个DataSource对象注册到名字服务中，应用程序就可以通过名字服务获得DataSource对象，并用它来产生一个与DataSource代表的数据源之间的连接

 

关于数据源的信息和如何来定位数据源：

例如，数据库服务器的名字，在哪台机器上、端口号等，都包含在DataSource对象的属性中。这样，对应用程序的设计就更方便，因为并不需要硬性地把驱动的名字固定到程序中。通常，驱动名字中都包含了驱动提供商的名字，而在DriverManager类中通常是这么做的。

如果数据源要移植到另一个数据库驱动中，代码也容易修改。所需要做的修改只是更改DataSource的相关属性，而使用DataSource对象的代码不需要做任何修改

 

2. 对连接池的支持

Connection Pooling(连接池)

DataSource对象的getConnection方法返回的Connection是否是一个连接池中的连接，完全取决于DataSouce对象的实现方法。如果DataSource对象实现与一个支持连接池中间层的服务器一起工作，DataSource对象就会自动返回连接池中的连接，这个连接也是可以重复利用的。

实际上，是否使用连接池获得一个连接，在应用程序的代码上是看不出不同的。在使用这个Connection连接上也没有什么不一样的地方，唯一不同的是在Java的finally语句中来关闭一个连接。在finally中关闭连接时一个好的编程习惯。这样，即使方法抛出异常，Connection也会被关闭并回收到连接池中。

try{...}catch(){}finally{if(con!=null){con.close();}}

总结

在一个基本的DataSource实现中，DataSource.getConnection方法返回的Connection对象和用DriverManager.getConnection方法返回的Connection对象是一样的。但DataSource无需硬件编码驱动，所以推荐使用DataSource对象来得到一个Connection对象。我们希望所有的基于JDBC2.0技术的数据库驱动都包含一个基本的DataSource实现，这样就很容易在应用程序中使用它

对于普通的应用程序设计者，是否使用DataSource对象只是一个选择问题。但是，对于那些需要用连接池或者分布式事务的应用程序设计者来说，就必须使用DataSource对象来获得Connection。