Combat. Net data Access Layer-12

Access | Data from this dalbase it is easy to see that the support of the Framework level is mainly concentrated

Above the cache management and distributed process, this is also almost

There are real issues that data Access logic have to consider (possibly in the actual project,

Data Access Logic level Distributed process requirements are not much, most

All in the business logic directly solved)!

Below, let's see how it is to make a real data Access logic

Convenient J



Code 10: Build Your own data Access Logic

Mydal: Provides data access support required by the current application, inheriting from Dalbase

public class Mydal:dalbase

{

Public Mydal () {}

}



Customerdal_adox: Provides support for data access using traditional ado.net, inheriting from Mydal

Class Customerdal_adox:mydal

{

Public Customerdal_adox () {}



protected internal MyCustomer Getcustomerbyid (string Strid)

{...}

protected internal void UpdateCustomer (MyCustomer Cust)

{...}

...

}



Customerdal_orm: Provides support for data access using O/R mapping, inheriting from Mydal

Class Customerdal_orm:mydal

{

Public Customerdal_orm () {}



protected internal MyCustomer getallcustomers ()

{...}

protected internal void UpdateCustomers (MyCustomer Cust)

{...}

...

}



































































The Mydal in the above code does not really implement what operation, purely for the sake of extension and set, the user can also resemble DAF, bypass Mydal this layer, directly let

Customerdal_adox or customerdal_orm inherit from Dalbase, which makes

Our system structure appears to be more concise and clear.



From the code above, it's easy to see that all data Access Logic

Methods are all declared as protected internal,why?

Of course, because of that "hateful" daf!. The price of interface consistency is right here.

Embodied (really hateful ah, the previous said so many of the reasons for the hype, to this

Then we'll talk about DAF's shortcomings. J)!

While being "stripped" of the data Access logic method directly in the code, "quick

Sense ", but if you really need to do this (strongly don't recommend J), there are still the following 3

Way of (of course, the author is very do not want you to put DAF into the doghouse,

After all, also spent a lot of effort and space greatly publicized a bit AH J):



(1) Compile your access code with data access logic into a assembly so that the magical internal will make you wish (DAF, data access logic belong to the data access module, Generally hit a assembly compiled, so naturally with the internal Magic j)! The cost is: you have to put business Logic (or other calling module) and data access in the same layer L, lost a good design of the system should have the sense of hierarchy and flexibility!

(2) Internal is a deep tool. NET features one of the 3 most common magic weapon (remind: do not abuse L), another weapon of course is our reflection!

Ok, also do not have your own shot, the system has already prepared a helper for you to enjoy:

public static Object InvokeMethod (

Type type, string method, object[] paramsvalue)

(3) If the preface or the system to provide the method is not good to use, it is only their own horse, I believe that you have already been able to reflection, envelope can easily take off (but, the author still want to remind a: do not abuse! Protected design Intent is very clear, cautious of the L)!



Said so much, or a sentence: quickly use DAF Bar, it (also) will make you happy

The J!



However, there is one question that needs to be made clear to everyone: Why does the author not

Use factory pattern to construct different data Access logic implementations (without using the

The cost of factory is the need to provide a large amount of configuration information to the method level, which is a bit

Trouble L)?

This is mainly based on 2 considerations:

(1) Data access logic does not necessarily comply with the DAF consistency principle, data entity is not the same (for legacy Data Access logic code, or even parameters may be different), in this case, define a generic Interface have a certain difficulty;

(2) Not every data access logic will implement all the features required by DAF (for example: In code 10 above, it is through Customerdal_adox and customerdal_orm two data access Logic to work together to build the full functionality of customer-oriented data access. Imagine, if the adoption of the factory, it is not "what do I have to do" Dongdong also to be forced to accept the whole? And, even if you write an empty method, how do you implement a real call to the other data Access logic (it's hard to write such a factory?).



Next paragraph: http://www.csdn.net/develop/Read_Article.asp?id=27555