Code 4: My Data Entity - 2, Data Entity in Framework
// Dafbase: Provide basic Data Entity support required to most applications,
// includes Collection, ADO.NET
[Serializable ()]
Public Abstract Class Defbase: IList, iDictionary
{
Protected interigin_typentity = entitytype.object;
// Collection Fields
Protected interunal arraylist _al = null;
Protected interunal hashtable _ht = null;
// ADO.NET FIELDS
Protected intenal dataset _dst = null;
Protected interface DataTable_tbl = NULL;
[Nonserialized ()]
Protected interNal dbdatarader _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;
}
...
}
The above is my Data Entity sample (finally seeing people J), is not
Is it very "cool"?
Frankly, according to my conservative estimates, more than 80% of friends will have the idea of "do not dare to share", and the other 15% may not be sure, there is always a similar taste. As for this left 5%, I am not very clear (I hope is the same as you are here), if a message tells me "This is what I want, please give me a source code.", It is estimated that I will have no hesitation without hesitation, no longer considering any license problem (if you don't receive a reply within 1 day, please believe that the author is happy to faint, or the internet has problems j)!
OK, simply explain:
Maybe you have noticed a problem, the deflection here is not Data
Entity's abbreviation, then what is this "F" represents something?
The previous mentioned that the author's data access layer solution starts with Data Access Façade (DAF), and the reference is of course the façade pattern in the GOF23, so in view of this, "f" in DEF is also included in the DEF. Façade meaning!
Is it a bit complicated? dizziness? There is no relationship, and listen to it!
The two classic Data Entity models given in Code 2 have their obvious advantages and weaknesses. Basically, in the actual development of the actual development, the actual development is in a unified way, it is inevitable to be inexpensive (there are some cases It is simple, and there are always some cases that make people's headaches). If, other factors that must be considered while adding the system architecture, such as: security, performance, scalability (interface / base class), scalability (load balancing / distributed processing), etc., for a slightly larger scale Enterprise Application, it is not difficult to understand why Data Access Layer is always then love and hate (Sigh, Data Entity is only the first step of thousands of miles L)! So, in order to solve this problem, the author feels necessary to do A relatively comparative generic solution, the first question to be solved is: Data Entity!
The so-called DEF, of course: Data Entity Façade, is white, it is one
The way the data is displayed in front of you! Here, it is not only a consistent access method (Interface), but also ensures different Data Entity models (Storage) under the consistent interface. And all this is hidden after a special set of Data Entity, it is the first step in the author DAF solution: Data Entity Façade! Not referred to as: DEF.
Next paragraph: http://www.9cbs.net/develop/read_article.asp? Id = 27548
