使用Enterprise Library DAAB架构灵活的数据提供层

前段时间提到使用DAAB模块引用到自己的系统中遇到的困惑：http://dragonpro.cnblogs.com/archive/2005/10/20/258486.html
后来经过我的反复思索和试验，找到了一种折中的方式，既尽量减少了重复代码屏蔽了数据库的异构问题，又可以较合理体现分层体系。现在抽空把这个架构分享出来，给大家多多少少一点参考，也希望多批评指正。

目的：

轻松切换数据库平台，在不修改业务逻辑的前提下切换数据库

尽量减少重复代码量，能抽象出来的抽象出来

降低维护成本

按照这三方面来考虑，参考了这么几种方式：

1. 单独建立DAL接口，在数据提供层分别实现这些接口，在应用层调用这些接口方法，另外还要工厂方法来实时装配这些实现，这适合在一些较小型的应用，比如.NET Petshop。优点是规范，性能好，缺点是维护较麻烦。

2. 在应用层提供抽象类的抽象方法，然后分别在数据层实现这些方法，在抽象类里使用Singleton模式使用静态方式加载实现层，这可以是一些较大型的应用，比如CommunityServer。优点是规范，性能好，缺点是代码量大，迁移维护较麻烦。

3. 还有就是微软提供的Entriprise Library DAAB模块，用次模块声称可以屏蔽调数据库的异构性。优点是可以尽量减少代码量，缺点是并不能完全屏蔽数据库异构，并没有声称的那么完美，比如Oracle多数据集的返回和其他一些特性，支持的并不好。

4. 用Hibernate类似的对象持久化技术。优点是可以可以规范对象和方便的持久层配置，缺点是不太灵活，也不适合在已有的系统中实现。

上面几种方式都是比较流行的做法，但有缺点和优点并存，作为追求完美的我们，想想能不能做到既可以很好的规范和性能又可以尽量减少代码维护的成本呢，我试着这么做了一下，其实就是折中了一下这几种方案。

using System;
using System.Data;
using Microsoft.Practices.EnterpriseLibrary.Data;

namespace DataProvider
using System;
using System.Data;
using System.Reflection;
using System.Configuration;

namespace DataProvider
using System;
using Microsoft.Practices.EnterpriseLibrary.Data;
using System.Data;
using System.Data.OracleClient;

namespace DataProviderOracle
/**//// <summary>
/// ExpmpleDataProvider 的Oracle实现
/// </summary>
public class ExpmpleDataProvider : IExampleDataProvider
public ExpmpleDataProvider()

}

/**//// <summary>
/// Oracle实现方法
/// </summary>
/// <returns></returns>
public override string ExampleMethod()
return "这是ExampleMethod的Oracle实现";
}

}//class
}//namespace