代码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。
