废话少说，先奉上代码若干，请大家一起参详参祥（以 SQL Server 所带 Northwind 为例）： ** **
代码 1 ：如何调用 DAF ？
// 创建 Customer 数据访问对象 ** **
** CustomerDaf ** daf = new ** CustomerDaf ** ();
// 根据 ID 返回 Customer 数据表
** DataTable ** cust1 = ( ** DataTable ** )daf.GetCustomerById("ALFKI");
// 根据名字返回匹配成功的 Customer 数据集
** DataSet ** cust2 = ( ** DataSet ** )daf.GetCustomers("ab");
// 根据名字返回 Customer 实体对象
** MyCustomer ** cust3 = daf.GetCustomerByName("Maria Anders");
// 返回所有 Customer 数据列表，每个列表元素代表一个 Customer 实体对象
** IList ** cust4 = daf.GetAllCustomers();
// 根据城市返回 Customer 数据读取器
** DbDataReader ** cust5 = ( ** DbDataReader ** )
daf.GetCustomerByCity("London");
// 将数据读取器数据转换为 Customer 数据列表，每个列表元素代表一个
// Customer 实体对象
** IList ** cust5_list =
** EntityConvert ** .ToList(cust5, typeof ( ** MyCustomer ** ));
代码 1 展示了通过 DAF 获取数据的几种基本操作，从中，我们不难看出： CustomerDaf 就是传统意义上的 数据访问类 ，而 Customer 则对应了 数据实体类 ，这种方式也是现在大部分 DAL 中最普遍使用的模式。既然如此，那么为何还要在此不厌其烦的推出这个 DAF （当然不仅仅是改个名字那么简单 J ），究竟意图何在？
回答这个问题前，先告诉大家一个事实：
虽然上面的代码总共返回了 5 种不同的 Data Entity 对象： ** DataTable ** ， ** DataSet ** ， ** MyCustomer ** ， ** Ilist ** ， ** DbDataReader ** ，但在 Customer 数据访问类“ ** CustomerDaf ** ”的定义中，所有方法的返回类型都是统一的 ** MyCustomer ** ！稍后，作者将对这段代码的实现部分进行分析。
Ok ，让我们先从数据实体类入手，看看传统的 Data Entity 到底是怎么做的：