Combat. Net data Access Layer-11

Access to | data 4. Data Access Logic

Discusses the data access Logic (in order to not be confused with data access layer, in this article

All of the parts that involve data access logic will all use the full name description, and the DAL refers only to the data access Layer, let's take a look at the schematic of its structure:






Hey! What's going on? Looks very similar to the DAF! Is this the

"Take pains" to carve out a separate section to "hype" the data Access

Logic?

That's right! This is the data Access logic! It's a bit like DAF, but

Is definitely not the twin brother, it plays the role also and DAF completely different!



The first thing to declare is that the similarity between Data Access logic and DAF does

exists, but it is embodied in the following two areas (which the authors consider to be not the main feature):

(1) They all adopted 2 inheritance models;

(2) The first two layers of Data Access logic (dalbase/mydal) are roughly equivalent to the first two layers of DAF, providing some basic services at the framework level and application level respectively.



In addition, however, the author needs to emphasize that Data Access logic

The key features are not in the first two layers (DAF is a bit different, and the first two layers are very important),

But in the real implementation of the specific data Access logic 3rd layer!

To make a simple analogy: DAF is a bit like interface in. NET, and the data Access logic is more like IMPLEMENTATIONJ.

So why don't the authors simply declare DAF as interface and let data Access logic directly inherit it? What are the reasons why we must strictly separate them and deal with them in different layer?



In fact, the reason is already part of the analysis (DAF needs to make sure that the interface declaration is consistent, the data entity is consistent, and that there is no limit to the Access logic), and that part of the reason is that DAF externally needs to uniformly advertise all interfaces, and data access Logic can be handled differently with relative flexibility. For example, ado.net related data access operations can be centralized in one place, while XML-related processing can be implemented in another place (is not more conducive to the refinement of Division J)!



There are two other situations that may also need to support this change:

(1) In the current release, we used some method to implement data Access Logic, such as: O/R Mapping, but in later versions, for some reason (performance/complexity), we need to use a dataset to interact, this time, The new method we write for the dataset makes it easy to replace the existing O/R mapping method (as long as the configuration information is modified), while the external interface (DAF) does not have to be modified at all (of course, the code that originally deals with the O/R mapping return data must be modified , but this does not break the interface consistency between cross layer)!

(2) The system may exist some legacy data Access logic code, this part of Dongdong discard, food is still lingering incense, how to do? Very simple, to DAF deal with it! We can create a separate data Access logic module (for example: customerdal_legacy) specifically include this part of the code, and then, in the DAF using adapter pattern to all of them into the door (of course, can also be in the private data The Access logic module is directly packaged, but the author prefers to use DAF to do such chores j)!



Ok, the text look tired, to paragraph code to see:



Code 9: Set off the hijab for data Access logic!

Dalbase: Provides basic data access support required by most applications.

including distributed processing, data caching support, etc.

public class Dalbase

{

Public dalbase () {}



Protected string Getdistributiontype ()

{

string strtype = null;

...//The required data is obtained from the current call context and configuration file

return strtype;

}

Protected Cacheparam Getcacheparam ()

{

Cacheparam param = null;

...//The required data is obtained from the current call context and configuration file

return param;

}

...

}