以下是DAF的结构示意图：
是不是看上去还比较简单？
根据以往的经验判断，在这种继承模式下，主要的开发工作全部集中到了DafBase和MyDaf身上，CustomerDaf的任务相对轻松，数据校验或者转换处理也并不是每个方法都需要的J
那么，DAF既然号称Façade，除了满足Façade之必要条件，还要起很好的表率作用，为上面的Data Entity Façade和下面的Data Access Layer作出一个榜样（也是一个桥梁），以下就是作者总结出的4大要素：
（1） 所有的数据访问请求全部通过DAF进行转发，无论是
Database还是XML，这都保证了数据访问接口的一致性；
（2） 对传入参数的校验以及返回结果的处理，全部在DAF中进行，这也确保了数据格式的一致性；
（3） 所有在DAF中声明的数据访问操作全部采用Data Entity Façade作为数据实体参与处理（这也是之所以采用Façade的原因之一），而下文所述的Data Access Logic则没有这个限制（可以直接使用诸如DataSet / DataTable / ObjectSet这样的框架类型作为数据实体）！
（4） 如果需要通过远程访问（例如：Remoting，WebServices）进行数据交换或处理（注意：不是在Business Logic中J），您可以选择在DAF中进行，也可以在具体的Data Access Logic中进行（请参考下文Data Access Logic中的论述）。
说到这里，大家是不是已经对DAF有个大概的印象了呢？
如果还不是很清楚，那么，下文即将推出的Data Access Logic（请注意：这里的Data Access Logic虽然也可简称为DAL，但和Data Access Layer是截然不同的两个概念！）就会进一步帮您看清DAF的真实面目J
下一段：http://www.csdn.net/develop/Read_Article.asp?id=27553 
|
本类阅读TOP10