Go back to the initial code 1, the author got five different Data Entity objects through DAF: DataTable, Dataset, Mycustomer, IList, DBDataRead, is strange, only the third call returns to real Data Entity Object: MyCustomer, isn't this conflict with the Data Entity Façade mentioned above?
And slow, the following code may illustrate some problems:
Code 5: How does DEF behave different data types?
// DEFBASE: Provides the basic data Entity support required to most applications,
// includes Collection, ADO.NET
[Serializable ()]
Public Abstract Class Defbase: IList, iDictionary
{
Public Static Implicit Operator Dataset (Defbase DEF)
{
Return DEF._DST;
}
Public Static Implicit Operator DataTable (Defbase Def)
{
Return DEF._TBL;
}
Public Static Implicit Operator DBDataReader (Defbase Def)
{
Return DEF._RDR;
}
...
}
The above DEFBASE illustrates four questions:
(1) For the inheritance interface, there is a certain amount of data type, such as: DataTable, DataSet, DBDataReader, all the Implicit Operator for internal data type conversion, the result of the conversion is the actual data type of Data Entity, which is more convenient, also Easy to expand (for example, you need to return to DataTable, you may change to DBDataReader or other data types in the future, at this time, the interfaces of Data Entity / Data Access are not required, and the caller is only used to use other Implicit Operator to access you. The data);
(2) Very convenient data type, such as iList, directly inherit the interface (the DBDataReader described above can also be implemented by inheriting the iDataReader, but due to the current ADOTAREADER) almost All from DBDataReader, so use the Implicit Operator more practical directly)!
(3) Regardless of the type above, Data Entity will maintain an object to actual data members, which reflects the true face of the data;
(4) For SINGLE Object, only need to expose the basic object field, you can use the Data Entity itself (MyCustomer), this is the same as we call Data Entity when the O / R mapping is called!
For issues that DEFBASE can't be resolved, you need to deal with specific applications. For example, considering generic factors, DEFBASE does not support XML data storage, and developers can create Customized Data Entity Facade in their own applications, allowing them to support XML, then, the specific Data Entity Class can directly from Customized Data Entity Façade inherits (of course, if the Data Entity Class does not need to support XML, you can inherit from DEFBASE) and use its XML support function! The MyDef / MyCustomer in the above code 3 is built for this purpose, both of which use Framework's function and can be expanded on this basis.
Next paragraph: http://www.9cbs.net/develop/read_article.asp? Id = 27549
