Combat. Net data Access Layer-10

Access | Data below is the schematic diagram of the DAF:




Does it look easier?

According to the past experience, in this mode of inheritance, the main development work is concentrated on the dafbase and MYDAF, CUSTOMERDAF task relatively easy, data validation or conversion processing is not required in every way J



So, DAF since the so-called façade, in addition to meet the necessary conditions for façade, but also to play a good role model for the above data Entity façade and the following data Access layer to make an example (also a bridge), Here are the 4 major elements that the authors have summed up:

(1) All data access requests are forwarded through DAF, whether

Database or XML, which guarantees the consistency of the data access interface;

(2) The validation of incoming parameters and the processing of return results are all carried out in DAF, which ensures the consistency of the data format;

(3) All data access operations declared in DAF use the data Entity façade as part of the database entity (which is one of the reasons for using façade), and the following information access Logic does not have this limitation (you can use a frame type such as dataset/datatable/objectset as a data entity directly)!

(4) If you need to use remote access (for example: remoting,webservices) for data exchange or processing (note: Not in the business logic j), you can choose to do in DAF, or in the specific data access Logic (refer to the discussion in the data Access logic below).



Speaking of which, do we have a general impression of DAF?

If it's not clear, then, the upcoming data access Logic (Note: Here's the data access Logic, although it can also be called DAL, but the two concepts are very different from the data Access layer!). Will further help you to see the true face of DAF J