这方面有很多好的Sample，最经典的莫过于微软大力推荐的企业级开发套餐：Duwamish。
举个简单的例子，Duwamish方案中并没有考虑Cache Management，
而这对于企业级应用来说，某些时候就是一个不得不考虑的问题；另一
方面，虽然Duwamish中告别了SQL语句（全部采用存储过程实现），
但数据库痕迹依旧十分明显，比如：某些字段名称的定义，关联表名称
的定义等等
还有一个十分头疼的问题是在开发过程中体现出来的。一开始，那
些比较简单的数据表还比较容易实现，到了一些包含相互关系的数据表
时，我们的DAL工程师就感到了压力，到后来，几乎又做了一遍DBA
在数据库建模时早已做过的工作，只不过，这次将数据库脚本换作了
C# 实现（或者说：将数据库结构换成了表面上具有OO特色的DataSet）
而已。
ADO.NET上另一个值得参考的DAL实现就是鼎鼎大名的PetShop。
当然了，与Duwamish相似，名气大未必真的实用。PetShop虽然
弥补了Duwamish在某些方面的不足，例如：通过Factory支持多种数
据库存储，引入了Cache机制，提供了更为便利的SQL Helper，但也同
时带来了另一些问题。其中，最麻烦的就是SQL语句的引入，而且还
是针对不同数据库存储的不同SQL语句（主要是SQL Server与Oracle
的参数表示方式不同）。
// 根据EmployeeID返回其Title
boEmp = new EmployeeDAL();
boEmp.Keys[“Emp_ID”] = 1; // 注意：实际字段名为：EmployeeID
boEmp.Select();
string strTitle = boEmp[“Emp_Title”]; // 注意：实际字段名为：Title
……
// 根据 City 返回所有符合条件的 Employee
boEmp = new EmployeeDAL();
boEmp.Keys[“Emp_City”] = “Seattle”;
boEmp.Select(); // 注意：该方法与上面的调用完全相同
DataTable dtEmp = boEmp.Table;
如果不考虑对象创建（可以采用Object Pooling或者Cached Object）以及调用后的处理，实际的代码只有两行！
上述EmployeeDAL类没有任何真正意义上的实现代码，仅仅是声明了类名，然后从一个通用基类继承而已！！
最优雅的地方还不在于此，实际上，就算在那个基类中，也根本看不到SqlConnection或者OracleAdapter之类的帮派之争。
相信大家也猜出来了，没错，它是借鉴了PetShop的实现，采用了Factory模式来保证DAL可以适用于不同的数据库存储。不过，这种实现与PetShop还是有很大的区别：至少，它没有产生不同的SQL语句，更没有出现不同的参数调用方式（SQL Server中一般使用“@”符号，Oracle中一般使用“：”符号），所有帮派一视同仁！c
这其中，当然得益于Factory的实现技巧，但更重要的因素还在于设计方式的精妙。其实，在.NET Framework中，已经提供了这种设计方式的基石，说白了，就是System.Data中的那些Interface（如：IDBConnection，IdataAdapter等）。