OK, the Dafbase above is just an Abstract Base Class (ABC), please continue
Look at the real DAF below:
Code 8: Let DAF work!
// myDAF: Provides the Data Access Support required for the current application, inheriting from Dafbase
Public Class MyDAF: Dafbase
{
Public mydaf () {}
Protected Override Defbase CallDalmethod
Object [] Paramsvalue)
{
...
Defbase def = base.callDalmethod (paramasvalue);
...
Return DEF;
}
}
// CustomerDAF: Contains the actual data access method declaration,
// Get data by calling DAL, inheriting from myDAF
Public Class Customerdaf: MyDAF
{
Public CustomerDaf () {}
Public MyCustomer getcustomerbyid (String Strid)
{
... // Check or convert incoming parameters
Mycustomer Cust = (MyCustomer) CallDalmethod
New Object [] {strid});
... // Modify or convert data results
Return CUST
}
Public mycustomed getcustomers (String Strname)
{
... // Check or convert incoming parameters
Mycustomer Cust = (MyCustomer) CallDalmethod
New Object [] {strname};
... // Modify or convert data results
Return CUST
}
...
}
The unified Data Access Logic call is pushed to DEFBASE (need to be configured)
Information is a series of "boring tasteless" processing), and the custom part is completed by yourself.
This is the real reason for MyDaf and CustomerDaf!
MyDAF is equivalent to the current ENTERPRISE APPLICATION basis,
Provide some basic services for the characteristics of the application, under this service, real
CustomerDaf can concentrate on specific Data Access Logic (unlike
Business logic) is processed, for example: basic verification before data access,
The resulting conversion operation is performed.
According to Ease of USE principles, we can also bypass this MYDAF, directly let
Customerdaf inherits from Dafbase, in this case, entire inheritance
Hierarchy is more simple.
Next paragraph: http://www.9cbs.net/develop/read_article.asp? Id = 27552
