不使用DalFactory和IDAL，支持多种数据库应用-白红宇

MS的PetShop示例应用程序的“多层架构”被很多.NET开发人员奉为经典的架构，我以前做的项目团队的Leader也是照搬它的，甚至来到现在这个公司后，好几个新来的同事建解决方案也是照搬PetShop的架构，可见PetShop对大家影响之深。

下面是PetShop 3.0的架构图：

为了支持多数据库应用，在DAL中，定义了DAL Interface和DAL Factory，下面这个图也许跟简单直观一些（引用园友中的图片，请见谅：))

通过这个图大家都能够明白，引入DalFactory和IDAL就是为了系统支持不同的数据库。

PDF.NET数据开发框架采用了完全不同的方式，先看看它的分层架构图：

如果在DAL中没有某种数据库特有的SQL语句，DalFactory是不需要的，当然IDAL也不需要了。例如ORM操作，一般不会用到数据库的特性，发出的都是标准的SQL语句。PDF.NET数据开发框架的ORM操作是通过EntityQuery和OQL表达式来实现，在具体支持不同数据库的时候，底层采用的是反射工厂模式：

 
///
 
<summary>
///
 创建公共数据访问类的实例
///
 
</summary>
///
 
<param name="providerAssembly">
提供这程序集名称
</param>
///
 
<param name="providerType">
提供者类型
</param>
///
 
<returns></returns>
        
public
 
static
 AdoHelper CreateInstance( 
string
 providerAssembly, 
string
 providerType )
         { 
             Assembly assembly 
=
 Assembly.Load( providerAssembly );
object
 provider 
=
 assembly.CreateInstance( providerType );
if
( provider 
is
 AdoHelper )
             { 
return
 provider 
as
 AdoHelper;
             }
else
             { 
throw
 
new
 InvalidOperationException(
"
当前指定的的提供程序不是 AdoHelper 抽象类的具体实现类，请确保应用程序进行了正确的配置（如connectionStrings 配置节的 providerName 属性）。
"
);
             }
         }

这样只需要在配置文件中进行配置，指明采用何种数据库即可，这是框架脱离DalFactory+IDAL的第一种方式。

当然，为了高效的使用某种数据库的特性，有可能会写一些数据库特性的SQL，要使得系统支持不同的数据库，还得使用DalFactory，因此得定义IDAL。

PDF.NET数据开发框架为了解决这个问题，将所有的SQL语句写在一个配置文件SqlMap.config中，使用工具自动生成框架的DAL代码，即SqlMapDAL，不同的数据库系统使用不同的SqlMap.config文件即可，不需要替换SqlMapDAL，因此，框架再也不需要定义DalFactory和IDAL了，这应该算是第二种方式。

下图是根据SqlMap自动生成代码并运行的流程：

在SqlMap中，可以将结果映射成DataSet，实体类和实体类集合，也可以是单值类型，可以完成各种复杂的SQL操作，可以处理存储过程。系统将SQL语句中的参数映射成DAL代码中方法的参数，使得操作非常直观高效，并且没有SQL注入的问题。

PDF.NET数据开发框架通过自己的ORM（EntityQuery+OQL）结合SQL-MAP的方式，使得喜欢OO的人和喜欢SQL的人都能找到自己需要的，便利性和灵活性都能够兼得。

详细请看官网介绍：

或者看我博客中的相关文章介绍。

本文转自深蓝医生博客园博客，原文链接：http://www.cnblogs.com/bluedoctor/archive/2011/04/01/2001887.html，如需转载请自行联系原作者