Analysis of data access layer technology under. Net (i)

Access | Data L Introduction

Since. NET really went into the developer's Day, "efficiency" two words has been a topic that many programmers relish. Whether it's from development mode (Cross Language), the system framework (. NET framework), or a variety of easy-to-use tools (vs.net), none of this reflects its victory.

At the same time, on the other hand, whether. NET is truly competent for the development of enterprise-class applications (Enterprise application) continues to be debated and mixed.

Generally speaking, there are many aspects to consider for an enterprise application, such as security, performance, scalability, ease of use, and so on. In this article, the authors are more than willing to work with you to explore the technologies in the. NET data access layer, which may be a sensitive topic of widespread concern since the creation of multi-tier architectures (N-tier architecture), which may be the most frustrating part of a project for most developers, Or even the most contentious part.

In the following discussion, for the sake of unification, the author temporarily referred to the data Access layer as the Dal (Layer).

L Analyze Problems

After simple statistical analysis, it is not difficult to find that the DAL is daunting, not because of the technology itself, but even on the contrary, which many developers consider to be one of the least technical components (in terms of the size of the project that the author has been experiencing, the development time is generally relatively short and many developers are unwilling to take the Drudgery "), only the architecture needs or some thought mischief (e.g., DAL) joins the so-called fourth layer (the traditional three-tier architecture does not present the DAL idea).

The DAL's proposal is a great challenge to the traditional architecture model, the goal of joining must also be to further improve productivity, in which case the ideal scenario is that most developers will be freed from the pain of the DBA, or even sever the direct relationship to the database, and that the SQL is going to leave us, The whole OO world is quiet.

However, the ideal of the ideal, can become a reality will need to pass the project test.



Next, the author tries to analyze several popular and more representative solutions to see if we can draw some valuable conclusions and provide some references for us to design and implement DAL in the future.



U ado.net

First, mention. NET under the DAL, immediately greeted is ado.net.

Yes, almost all DAL solutions (please allow authors to use solution rather than

Framework) must be developed from it, there is no choice, this is also a. NET feature of

Implementation method (compared to Java).

Excluding business factors and the needs of the CLR itself, ADO. NET really brings us something

Not much, it is worth mentioning also on the dataset (in terms of the author's experience of the project, the use of more is

DataTable and DataView). From Microsoft's early memory databases (Memory database)

Few people have come to today's dataset, and the twists and turns are not word

To be able to do, in short, one thing is certain, it is with the dataset of this choice. NET under

Dal in order to blossom like today, everyone's ideas can be more open.



Duwamish

There are a lot of good sample, the most classic is Microsoft's highly recommended Enterprise development package: Duwamish.

For the hope of learning. NET under the Dal design friend, this is a good starting point, which

Aspects of the complete analysis, you can refer to the "CSDN development Master, 2003.11", this article does not

Repeat it again.

The Duwamish program was used in one of the projects that the author was involved in and was limited to

Period, feel this is a good reference, did not do in-depth analysis began to design. Now think back

Up, found that there are still many deficiencies.

As a simple example, the cache Management is not considered in the Duwamish scheme.

And this is a problem that has to be considered at some point in an enterprise-class application;

Aspect, although Duwamish the SQL statement (all using the stored procedure implementation),

But the database traces are still very obvious, such as: the definition of some field names, associated table names

The definition and so on.

There is also a very troubling problem that is reflected in the development process. At first, that

Some of the simpler data tables are easier to implement, to some of the data tables that contain the interrelationships

, our DAL engineer felt the pressure, and then, almost again, the DBA

The work that has already been done while modeling the database, but this time the database script is changed

C # implements (or, instead, replaces the database structure with a surface OO-specific dataset)

Just.

Perhaps, Duwamish's implementation is more classic, but in practical applications, sometimes it does not mean

Taste the best Practice. Just take our project, though successfully delivered, but whatever from modulo

Type multiplexing angle, or development efficiency, are not very successful. To apply a popular phrase:

In fact, we can do better!



PetShop

Ado. NET on another worthy of reference Dal implementation is the famous PetShop.

Of course, similar to Duwamish, fame is not really practical. PetShop though

Make up for Duwamish in some ways, such as: Support multiple numbers through factory

According to the library storage, the cache mechanism is introduced, which provides a more convenient SQL Helper, but also

Brings with it some other problems. Among them, the most troublesome is the introduction of SQL statements, but also

are different SQL statements stored for different databases (primarily SQL Server and Oracle

differ in the way that the parameters are represented.

PetShop, on the other hand, did not use the dataset to replace it with a simpler ordinary

Entity Object (Model), but it also converts the result of the DataReader to the containing entity

As the list of images for offline use, in this sense, is a mixture. Even

In some cases, such as the need for data filtering, or navigating between master and slave data, instead

More inconvenient (at this point, the simple collection or list is not enough to meet the requirements, the DBA

The DAL developer can only provide other methods to achieve the goal.



From the above two examples, we can see that even in Microsoft's development team,

Failed to agree on the DAL issue. More detailed information in this regard, interested in

Friends can refer to the following articles:

Http://www.microsoft.com/china/community/Column/67.mspx.



Actual combat

The two solutions that are profiled above let us see their respective strengths and weaknesses, and the complex environment of enterprise applications is unlikely to require a universal framework to solve all the challenges, and therefore can only be analyzed on the basis of specific circumstances.

The author has been involved in a (. NET) Large-scale outsourcing project development work, was fortunate to see its dal design thought, deeply shocked, here and friends together to discuss.

As an example of SQL Server's Northwind database, the following is a call code based on the Dal (the author makes some name adjustments):



Return its title according to EmployeeID

Boemp = new Employeedal ();

boemp.keys["emp_id"] = 1; Note: The actual field name is: EmployeeID

Boemp.select ();

String strtitle = boemp["Emp_title"]; Note: The actual field name is: Title

......

Return all eligible Employee according to City

Boemp = new Employeedal ();

boemp.keys["emp_city"] = "Seattle";

Boemp.select (); Note: This method is exactly the same as the previous call

DataTable dtemp = boemp.table;



If you don't consider object creation (you can use object pooling or cached object) and the processing after the call, the actual code has only two lines!

Even more surprising, the above Employeedal class does not have any real code of implementation, simply declares the class name and inherits from a common base class!!

The most elegant place is not in this, in fact, even in the base class, there is no SqlConnection or oracleadapter of the gang dispute.

I believe you also guessed it, yes, it is based on the implementation of PetShop, using the factory model to ensure that the DAL can be used for different database storage. However, this implementation is still very different from the PetShop: at least, it does not produce different SQL statements, there is no different method of parameter invocation (SQL Server generally use the "@" symbol, Oracle commonly used ":" symbol), all gangs alike!

This, of course, benefits from the implementation of factory skills, but the more important factor is the exquisite design methods. In fact, in the. NET framework, the cornerstone of this design approach has been provided, plainly speaking, the System.Data of those interface (such as: Idbconnection,idataadapter, etc.).

On the basis of this design, we no longer need to provide different data access implementations for different database storage for each DAL class. For example, in PetShop, an order class needs to be implemented for orders data, and it is natural that the system implements the ordering class for SQL Server and Oracle separately and uses different provider (SqlClient, OracleClient) provides methods for operation. And in the actual call, PetShop through the Factory mode to create a real order class and activate the corresponding method, a different database storage scheme is leaps.

In fact, petshop this scheme has been more flexible, if more can save the "write different order class" of the bitter, it really sent the Buddha to the day J. And all of these features have been completely taken care of by the authors involved in this project!

As for the above "employeedal (of course, all other DAL classes) without any real implementation code", it's just a little bit of a configuration trick: to separate the Dal class from the associated stored Procedure (Note: Not table or view) is stored in the XML file separately according to namespace.

As you may have seen, in theory, even a Dal class can do all the work! However, in practice, different DAL classes may still have some small differences in data processing (such as: Data validation, format conversion, etc.).

Overall, in such a large project, it is not possible to require all developers (except the Dba,dal Framework Developer) to understand all aspects of ado.net, although the author of this quite a study, but in this project, but only to use two classes: Datatable,dataview (even transaction do not need to understand)!