实战 .Net 数据访问层 - 12
2024-07-10 13:03:21
供稿：网友
本文来源于网页设计爱好者web开发社区http://www.html.org.cn收集整理，欢迎访问。从这个dalbase很容易看出，framework level的支持主要集中
在cache management和distributed process上面，这也几乎是所
有data access logic都不得不考虑的现实问题（可能在实际项目中，
data access logic level的distributed process需求不会很多，大部分
都在business logic中直接解决了）！
以下，就让我们看看制造一个真正的data access logic是多么的
方便j
代码10：打造自己的data access logic
// mydal：提供当前应用程序所需的数据访问支持，从dalbase继承
public class mydal : dalbase
{
public mydal() { }
}
// customerdal_adox：提供使用传统ado.net进行数据访问的支持，从mydal继承
class customerdal_adox : mydal
{
public customerdal_adox() { }
protected internal mycustomer getcustomerbyid(string strid)
{...}
protected internal void updatecustomer(mycustomer cust)
{...}
...
}
// customerdal_orm：提供使用o/r mapping进行数据访问的支持，从mydal继承
class customerdal_orm : mydal
{
public customerdal_orm() { }
protected internal mycustomer getallcustomers()
{...}
protected internal void updatecustomers (mycustomer cust)
{...}
...
}
上面代码中的mydal并未真正实现什么操作，纯粹为了扩展而设置，用户也可以类似daf中那样，绕过mydal这层，直接让
customerdal_adox或customerdal_orm从dalbase继承，这会使
我们的系统结构显得更加简洁明了。
从上面的代码中，我们很容易地发现，所有data access logic
方法全部被声明为protected internal，why？
当然还是因为那个“可恨的”daf！接口一致性的代价就在这里
体现出来了（真可恶啊，前面说了那么多天花乱坠的原因，到了这
么后面才谈daf的缺点j）！
虽然被“剥夺”了在代码中直接点出data access logic方法的“快
感”，但如果您真的非常需要这么做（强烈不推荐j），还是有如下3
个办法的（当然了，作者是非常不希望您就这么将daf打入冷宫，
毕竟也花了好多心血和篇幅大大的宣传了一番啊j）：
（1） 将您的访问代码与data access logic编译进一个assembly中，这样，神奇的internal就会使您心想事成（daf、data access logic同属data access模块，一般打进一个assembly编译，所以天然具有了internal魔力j）！付出的代价则是：您不得不将business logic（或其它调用模块）与data access放在同一个layer中l，失去了一个良好设计的系统所应有的层次感和灵活性！
（2） internal是深具.net特色的3大惯用法宝之一（提醒：请勿滥用l），另一武器当然就是我们的reflection啦！
ok，也不用您自己出手，系统早已准备了helper供您享用：
public static object invokemethod(
type type, string method, object[] paramsvalue)
（3） 如果手痒或嫌系统提供的方法不好用，那就只有自己出马了，相信，您对reflection也早已滚瓜烂熟，三下五除二就能轻松拿下了（不过，作者还是要提醒一句：千万不要滥用！protected的设计意图非常明确，慎之慎之l）！
说了那么多，还是一句话：快用daf吧，它（也）会让您快乐
的j！
不过，有一个问题也需要向大家交待清楚：这里，作者为何没有
使用factory pattern来构造不同的data access logic实现（不使用
factory的代价是需要提供到method级别的大量配置信息，确实有点
麻烦l）？
这主要基于2个考虑：
（1） data access logic不一定会遵守daf的一致性原则，data entity也不尽相同（对于遗留data access logic代码，甚至连参数都有可能存在差异），这种情况下，定义一个generic interface有一定困难；
（2） 并不是每个data access logic都会实现daf要求的所有功能（比如：上面的代码10中，就是通过customerdal_adox与customerdal_orm这两个data access logic来共同构筑起面向customer进行数据访问的全部功能。试想一下，如果采用了factory，岂不是“与我何干”的东东也要被迫全盘接受？而且，即使写个空方法接受了，又如何实现对其它data access logic的真正调用（写这样的factory可真有点难度啊？
下一段：http://www.csdn.net/develop/read_article.asp?id=27555
