DAL的提出, 加入的目的是希望借其进一步提高生产效率,在这种模式下,理想情况是:大部分开发人员从此摆脱DBA之苦,甚或彻底断绝与数据库的直接关系,SQL之痛将离我们而去,整个OO世界从此清静
这方面有很多好的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等)。
转载于:https://www.cnblogs.com/dxxhh/archive/2005/11/18/279259.html