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