4. Data Access Logic
Discuss Data Access Logic (in confusing with Data Access Layer,
All parts involving Data Access Logic will use full name description, DAL only refer to Data Access Layer, let us first look at its structure diagram:
what! what happened? It looks very similar to DAF! Is this that it is
"Don't help but" open up a section for "Daxie Propaganda" Data Access
Logic?
That's right! This is Data Access Logic! It is a bit like DAF, but
It is definitely not a twin brother, and the role it will also be completely different from DAF!
First, it is necessary to declare that the similarity between Data Access Logic and DAF is indeed
The existence, but it is reflected in the following two aspects (the author thinks this is not its main feature):
(1) They all have 2 inheritance modes;
(2) Data Access Logic's first two-layer (Dalbase / Mydal) is equivalent to the first two layers in DAF, providing some basic services in Framework Level and Application Level, respectively.
However, in addition, the author needs special emphasis on Data Access Logic
Key features are not in the top two layers (DAF is a bit different, its first two layers are very important),
Instead, in the 3rd floor of specific Data Access Logic!
Match a simple bit: DAF is a bit like the .NET in Interface, while Data Access Logic is more like ImplementA.
So, why not directly declare the DAF to Interface to inherit Data Access Logic directly? What is the reason for us to strictly separate them, and do it in different Layer?
In fact, the reason has been analyzed above (DAF needs to ensure that the interface declaration is consistent, the data entity is consistent, and Data Access Logic is not limited. The reason is that the DAF is unified to publish all interfaces, while Data Access Logic Different processing can be performed relatively flexibly. For example: You can concentrate the ADO.NET access operation in one place, while XML-related processing places can be implemented in another place (is it more conducive to fine division of labor J)!
There are also two situations that may also need to support this change:
(1) In the current version, we use some way to implement Data Access logic, for example: o / r mapping, but in subsequent versions, due to some reasons (performance / complexity), we need to modify the DataSet mode to interact At this time, we can easily replace existing O / R mapping methods for DataSet, and simply modify configuration information), and the external interface (DAF) does not have to be modified (of course, it turns against O / R mapping Returns the code of the data is handled, but this does not destroy interface consistency between Cross Layer)! (2) There may be some legic Data Access Logic code in the system. This part of the Dongdong is unfortunately, and if the food is still, what should I do? Very simple, hand it over to DAF! We can create a Data Access Logic module (for example, Customerdal_legacy) to include this part of code, then use Adapter Pattern to use Adapter Pattern to enter the door in DAF (of course, you can also pack in this dedicated Data Access Logic module) But the author prefer to use the DAF to do such a minimity J)!
OK, the text is tired, come to the code:
Code 9: Set off the cover of Data Access Logic!
// Dalbase: Provides basic data access support required for most applications,
/ / Include distributed processing, data cache support, etc.
Public Class Dalbase
{
Public dalbase () {}
protected string getDistributiontype ()
{
String straType = NULL;
... // Get the required data according to the current call context and the configuration file
Return straTrtype;
}
protected cacheparam getcacheparam ()
{
Cacheparam param = null;
... // Get the required data according to the current call context and the configuration file
Return Param;
}
...
}
Next: http://www.9cbs.net/develop/read_article.asp? Id = 27554
