关闭

数据库访问层设计与实现(1)

1866人阅读 评论(0) 收藏 举报

数据库访问层设计与实现

2006-05-28

 

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

 

1 引言

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

1)数据库类型是变动的

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

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

2)主键生成的规则不同

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

3)数据库连接管理

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

4SQL语句安全性检查

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

5)程序中SQL语句到处飞

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

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

 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:114209次
    • 积分:1393
    • 等级:
    • 排名:千里之外
    • 原创:45篇
    • 转载:4篇
    • 译文:0篇
    • 评论:8条
    最新评论