Ok，上面的DafBase只是个Abstract Base Class（ABC），请继续
看下面的真正Daf：
代码8：让DAF工作起来！
// MyDaf：提供当前应用程序所需的Data Access支持，从DafBase继承
public class MyDaf: DafBase
{
public MyDaf() { }
protected override DefBase CallDalMethod(
object[] paramsValue)
{
...
DefBase def = base.CallDalMethod(paramsValue);
...
return def;
}
}
// CustomerDaf：包含实际的数据访问方法声明，
// 通过调用DAL获取数据，从MyDaf继承
public class CustomerDaf: MyDaf
{
public CustomerDaf() { }
public MyCustomer GetCustomerById(string strId)
{
... // 检查或转换传入参数
MyCustomer cust = (MyCustomer)CallDalMethod(
new object[] { strId });
... // 对数据结果进行修改或转换
return cust
}
public MyCustomer GetCustomers(string strName)
{
... // 检查或转换传入参数
MyCustomer cust = (MyCustomer)CallDalMethod(
new object[] { strName });
... // 对数据结果进行修改或转换
return cust
}
...
}
统一的Data Access Logic调用推给DefBase完成（需要根据配置
信息进行一系列“枯燥无味”的处理），自定义部分才由自己来完成，
这就是MyDaf和CustomerDaf出现的真正原因！
MyDaf相当于当前Enterprise Application的数据访问基础，可以
针对应用程序的特点提供一些基本的服务，在此服务下，真正的
CustomerDaf就可以集中精力对具体的Data Access Logic（不同于
Business Logic）进行处理了，例如：数据访问前的基本校验，对返
回结果进行转换操作等。
根据Ease of Use原则，我们也可以绕过MyDaf这层，直接让
CustomerDaf从DafBase继承，在这种情况下，整个Inheritance
Hierarchy就显得更加简单了。