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就显得更加简单了。