在将 ADO 可靠地并入 MDAC后,Microsoft 掀起了通用数据访问的使用高潮。其主导思想是向开发人员展示,通过使用简单的对象模型,可以编写出能够与各种不同的数据源连接的应用程序。
CustomersData 类实现 IdbCustomers 接口。需要支持新数据源时,只能创建一个实现该接口的新类。
此类型的接口可以类似于如下所示:
using System;
using System.Data;
namespace Common
{
public interface IDbCustomers
{
DataTable GetCustomers();
DataTable GetCustomerOrders(string CustomerID);
DataTable GetCustomersByCountry(string CountryCode);
bool InsertCustomer();
}
} |
我们可以创建专用程序集或共享程序集来封装这些数据访问类,在第一种情况下,程序集加载程序将搜索我们在 ApPBase 文件夹的配置文件内指定的程序集,或者使用典型探测规则在子目录内进行搜索。如果我们必须与其他应用程序共享这些类,则可以将这些程序集置于全局程序集缓存中。
从其他层使用数据访问类
这两个几乎相同的 CustomersData 类包含在应用程序其余部分将使用的两个不同程序集内。通过下面的配置文件,我们现在可以指定要加载的程序集以及面向的数据源。
可能的配置文件示例将类似于如下所示:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionString"
value="Server=(local);Database=Northwind;
User ID=UserDemo;Pwd=UserDemo" />
<add key="DALAssembly" value="DALAccess,
version=1.0.0.0, PublicKeyToken=F5CD5666253D6082" />
<!-- <add key="ConnectionString"
value="Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=..\..\..\Northwind.mdb" />
-->
</appSettings>
</configuration> |
我们必须在此文件内指定两条信息。第一条信息是规范的连接字符串(用于为更改提供机会),如服务器名称或其他一些用于连接的参数。第二条信息是程序集的完全限定名,应用程序的上一层将动态加载此程序集以查找与特定数据源一起使用的类:
让我们再来看一下这部分代码:
using System;
using System.Data;
using System.Configuration;
using System.Reflection;
using Common;
namespace BLL
{
public class Customers
{
public DataTable GetAllCustomers()
{
string AssemblyName =
ConfigurationSettings.AppSettings
["DALAssembly"];
string TypeName = "DAL.CustomersData";
IDbCustomers cd =
//(IDbCustomers)=
Assembly.Load(AssemblyName).
CreateInstance(mytype);
DataTable dt = cd.GetCustomers();
return dt;
}
public DataSet GetCustomerOrders()
{
// 待定
return null;
}
}
} |
您可以看到,程序集使用从配置文件中读取的名称进行加载,并创建和使用 CustomersData 类的实例。