实战 .Net 数据访问层 - 5
2024-07-10 12:57:19
供稿：网友
代码4：我的data entity – 2，framework中的data entity
// dafbase：提供大部分应用程序所需的基本data entity支持，
// 包括collection，ado.net
[serializable()]
public abstract class defbase : ilist, idictionary
{
protected internal string _typeentity = entitytype.object;
// collection fields
protected internal arraylist _al = null;
protected internal hashtable _ht = null;
// ado.net fields
protected internal dataset _dst = null;
protected internal datatable _tbl = null;
[nonserialized()]
protected internal dbdatareader _rdr = null;
public defbase() { }
public defbase(arraylist al)
{
this._al = al;
this._typeentity = entitytype.collection_arraylist;
}
...
public defbase(dataset dst)
{
this._dst = dst;
this._typeentity = entitytype.adox_dataset;
}
public defbase(datatable tbl)
{
this._tbl = tbl;
this._typeentity = entitytype.adox_table;
}
...
}
以上，就是我的data entity小样了（终于又要见人了j），是不
是感觉很“酷”啊?
坦率地讲，根据我的保守估计，八成以上的朋友会有“不敢苟同”之想法，而另外15%可能是不能确定，总有似曾相识（四不象？）却又不尽相同的味道。至于这剩下的5%，我就不是很清楚了（希望是所见略同吧），如果哪位写邮件告诉我“这正是我想要的，请你给我一份源码吧”，估计我会毫不犹豫的立即奉上而不再考虑任何license问题（如果在1天内没有收到回复，请您相信是作者开心得晕过去了，要不就是internet出问题了j）！
ok，简单解释一下：
可能大家已经注意到一个问题，这里的def好像并不是data
entity的缩写，那么，这个“f”到底代表什么呢？
前面曾经提过，作者的这个数据访问层解决方案起名字为data access façade（daf），参考的当然是gof23条中的façade pattern，所以，有鉴于此，这里def中的“f”同样包含着façade意思！
是不是有点复杂了？头晕？没有关系，且听一一道来！
代码2中给出的两种经典data entity模式各有其明显的优缺点，基本上，就作者了解的情况，实际开发中都是以一种统一的方式进行抉择，难免就顾此失彼（总有些case是简单的，也总有些case是让人头疼不已的）。如果，再加上系统架构时必须考虑的其它因素，如：安全，性能，可扩展性（接口/基类），可伸缩性（负载均衡/分布式处理）等，对于一个稍微上点规模的enterprise application，也就不难理解为何data access layer总是那么让人又爱又恨了（sigh，data entity才只是万里长征第一步啊l）!
所以，为了解决这个问题，作者感觉有必要搞一个相对比较generic的解决方案，所要解决的第一个问题就是：data entity！
所谓的def，当然就是：data entity façade，说白了，就是以一
致的方式将数据展现在您的面前！这里的一致，不仅仅意味在当前应用程序中表现出一致的访问方式（interface），还要能够确保在一致的interface下支持不同的data entity模型（storage）。而所有这一切，都被隐藏在了一个特别搭建的data entity之后，它，就是作者daf解决方案中的第一步：data entity façade！简称为：def。
下一段：http://www.csdn.net/develop/read_article.asp?id=27548
