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就显得更加简单了。
下一段:http://www.csdn.net/develop/Read_Article.asp?id=27552