在项目的开发过程中在设计模式的概念还没有出来时我们那时候在编写程序时往往如果项目的数据库是采用SQL Server然后用户又想换其它数据库如Oracle时我们就需要对其代码进行重写特别是在一些软件的产品化道路中我们做出来的产品如果让用户可以有选择的去选取各种数据库那无疑对用户提供了很大的方便
自从工厂模式的设计理念出来以后这一切实现就变得容易得多如果大家对微软的PETSHOP有研究的话那就不会陌生了从PETSHOP开始微软就开始采用了多数据库操作系统的应用数据工厂主要是通过把数据库的连接做成一个抽象的工厂如命名DALFactory程序中所有的数据库连接都通过这个工厂类来产生用来负责根据配置文件动态创建系统所需的数据访问逻辑对象
我们就拿PETSHOP来举例说明PETSHOP在安装的时候会提示我们选择什么数据库如根据显示的是SQL Server数据库还是Oracle数据库可以得到nfig的节点中的
<add key= WebDAL value= PetShopSQLServerDAL />
<add key= OrdersDAL value= PetShopSQLServerDAL />
或者是
<add key= WebDAL value= PetShopOracleDAL />
<add key= OrdersDAL value= PetShop OracleDAL />
然后在DALFactory项目的DataAccess类中调用数据库的连接代码如下
private static readonly string path = ConfigurationManagerAppSettings[WebDAL];
然后再看下面的代码
public static PetShopIDALICategory CreateCategory() {
string className = path + Category;
return (PetShopIDALICategory)AssemblyLoad(path)CreateInstance(className);
}
如我们使用的是SQL Server那么string className = path + Category返回的就是PetShopSQLServerDAL Category然后再用AssemblyLoad加载PetShopSQLServerDALDLL同时创建PetShopSQLServerDALCategory的实例并以接口(PetShopIDALICategory)类型返回这样业务逻辑层BLL调用ICategory接口时就会用PetShopSQLServerDALCategory类的实现代码
这时候用户就不需要知道后台使用的到底是哪一种数据库它只要调用接口就行了在接口中定义了要使用的方法当调用接口时会根据具体的情况再去调用底层数据访问操作而现在这个DALFactory就是关键当业务逻辑层要操作数据库时DALFactory会根据具体情况再去使用生成的程序集SQLServerDAL或者OracleDAL中的一个这样做的好处是对于业务逻辑层及WEB页面层的程序不会因为底层数据访问的程序变动而受到影响因为只需要在业务逻辑层中调用接口就行了
有可能有人会提我同样在工厂类里面提供下面的方法去实现调用数据库
public static readonly DALFactory dalFa;
string webDal = ConfigurationManagerAppSettings[WebDAL];
switch (webDal)
{
case SQLServerDAL:
dalFa = new SqlServerDALFactory();
break;
case OracleDAL:
dalFa = new OracleDALFactory();
break;
default:
dalFa = new SqlServerDALFactory();
break;
}
而这个时候如果我们增加了新的数据库访问方式就必须得修改此部分的程序
然后再重新进行编译部署而同样利用反射的机制去实现的时候我们举个例子如果系统中现在需要增加MySQL数据库的时候我们来看看它的代码的可扩展性我们可以比较PETSHOP中的SQLServerDAL下面的Categorycs文件和OracleDAL下面的Categorycs文件的代码可知道因为它们都继承了ICategory接口所以类实现的方法都相同这时候我们只需要增加一个MySqlDAL项目其下面的Categorycs文件也同样遵循ICategory接口的方法这时候我们再去修改为
这个时候都不需要重新对项目进行编译只需要增加MySqlDALDLL文件就可无论增加多少数据库都是一件很简单的操作数据工厂操作多数据的优点就明显可见
