数据库访问层设计与实现（1）

数据库访问层设计与实现

狂※痴

2006-05-28

 

摘要：为了使上层的应用不依赖于下面具体数据库的类型，建立一个数据库访问中间层是必要的。实现了一个数据库访问层中间件，使得上层应用不用纠缠与具体数据库类型问题，能根据应用环境的不同，灵活选择连接的管理方式、关键字的生成规则以及SQL语句的安全性检查方式等等。给出了数据库访问层的设计思想以及在.NET中的实现。

 

1 引言

在近期使用.NET开发项目时，发现这样一些问题，影响着程序的复用性和软件的灵活性：

（1）数据库类型是变动的

原因有两个：一是因为不同的客户，对同一个应用程序的性能要求或费用开销不同，要求使用的数据库类型不同；二是我们在开发程序时，在不同的使用环境下，需要使用不同类型的数据库。

比如，如果使用ACCESS数据库，那么在程序中会使用System.Data.OleDb命名空间下的类，如OleDbConnection，OleDbParameter，OleDbDataAdapter等等。如果现在要求支持SQL Server数据库该怎么办呢？那么就需要修改现有的大量的代码，将System.Data.OleDb下的类全部替换为System.Data.SqlClient命名空间下的类，即使是使用“查找/替换”进行批量的修改，也是非常繁琐，也很容易出错。当然还会存在一些错误，比如，OleDb是使用“?”来传递参数的，而SQL Server中使用的是命名参数（如，“@para”）。因此还需要修改大量的SQL语句，麻烦啊！

（2）主键生成的规则不同

不同应用环境下，可能使用不同的主键生成策略，有的需要使用全局不重复的主键，有的需要加入时间或其他标记，有的只使用简单的计数器就可以。如果程序中写死了，下次环境变了，需要使用新的规则时，就又得改代码喽。

（3）数据库连接管理

控制连接的数目，有时时单个连接，有时是若干个连接，有时使用连接池……

（4）SQL语句安全性检查

为了防止恶意攻击，需要对SQL进行检查。有很多种检查方法，究竟使用哪个呢？

（5）程序中SQL语句到处飞

如果使用关系数据库，SQL语句是少不了的。但是SQL语句在应用层出现太多，一旦数据库发生变化，那么上层需要修改的SQL语句就太多了，而且在编译时发现不了SQL语句的错误，在运行时才能找到。另外大量的SQL语句，还严重影响了程序的美观。

对于上面的问题，最好的解决方法就是建立一个数据库访问中间层，来屏蔽这些问题。（当然有一些现成的框架，如NHibernate，可以使用，不需要我们自己动手。）本文后续部分将讨论如何解决这些问题，主要在如何设计，并给出部分实现。