访问|数据代码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