以下是 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