一、传统DB访问接口缺点

    众所周知，数据库的类型很多，常见的有Oracle、DB2、SQL Server、MySQL、Informix等等，但是不同的数据库拥有着不同的访问方式。如：可通过PRO*C、OCI访问Oracle；可通过ESQL访问DB2和Informix；可通过MySQL API访问MySQL等等。

    可是，往往完成基于某一种数据库的程序开发后，要切换至其他数据库时，不得不去修改数据库的访问接口、参数以及其他相关代码。这样势必造成代码的复用性不高，同时，也无形中增加了维护和开发的难度及成本。

    基于以上原因，现提出设计和实现统一数据库互联(UDBC: Unified DatabaseConnectivity)方式，来屏蔽数据库之间以及访问方式之间的差异，以此来提高开发效率和降低维护难度与成本。

二、UDBC的设计和实现

 2.1 架构设计

    假设存在三种API，分别能访问Oracle、Informix和DB2。

    2.1.1 传统API调用架构

图1  传统API调用架构

    如图1所示， ProgramA是基于Oracle数据库的已开发完成的原始程序。当需要切换数据库为Informix时，则需要对数据库相关的接口、参数及其他相关代码进行修改；当要切换数据库为DB2时，也需要对数据库相关的接口、参数及其他相关代码进行修改；当要开发与MySQL、SQL Server、FoxPro等等时，可发现工作量大，重复劳动多，复用性低等弊端就显现出来！！ 

    2.1.2 UDBC调用架构

图2  UDBC调用架构

    如图2所示，ProgramA是基于DB统一访问接口开发的程序，因此ProgramA既能够访问Oracle，同时也能够访问Informix，还能够访问DB2等等数据库。一旦要切换数据库时，不用对ProgramA的代码做任何的修改，程序依然可以正常的工作。

　2.1.3 UDBC架构

图3　UDBC架构

 2.2 架构实现

    2.2.1 UDBC内部结构

　由图3 UDBC架构可进一步细化各组件内部结构：

图4 组件API

     为减少各模块的偶尔性，我们采用组件的设计方式，各组件都有对外的API。UDBC要访问数据库时，其必然需调用对应数据库的访问接口，也就是说当程序调用UDBC访问Oracle时，DB-API将会调用Oracle-API；当程序调用UDBC访问Informix时，DB-API将会调用Informix-API；当程序调用UDBC访问DB2时，DB-API将会调用DB2-API。

    2.2.2 UDBC实现

    基于以上的分析，可知DB-API将会调用Oracle-API、Informix-API、DB2-API中的一种。出现这种情况时，我们往往会想到使用策略模式（策略模式：用统一的方法接口分别对不同类型的数据进行访问）。因此，可在DB-API层设计一个结构体来存放各函数的回调指针：（策略模式）

图5 回调指针

    回调指针初始化过程如下：

图6 回调初始化