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

Access to | data other

To end the Ado.net analysis, we had to mention DataReader and the dataset between the brothers

of contention.

In the light of the information that the author has read, almost all of them suggest a concrete analysis of the actual situation, leaving

Very few are determined by personal habits.

In the study of Ado.net, the author is also holding the idea, and repeatedly remember the information

The terms that are summed up (like when you learned Gof 23, you can almost reverse

The idea of a day can also be ado.net under the sun.



Unfortunately, the reality is not willing to do a number of consecutive projects, regardless of the size of the whole

Using a DataSet Solution!

At this point, look back at the most frequent petshop projects when learning ado.net,

The comparison of the two phases shows a hint of the clue.



Simply put, PetShop uses the following "curve salvation" approach to achieve data

Exchange:



DataReader Get Data => Create a Data entity class => fill the number of fields by field type

Entity class => adds a data entity to a list class (only for those that return more than one piece of data

Occasions

(Supplementary: The use of data entity classes or collection classes can be more convenient to achieve cache manament,

But the ordinary DataReader because of its data reads the way limit, cannot satisfy this kind of demand.



This process has the same effect as DataAdapter.Fill (), except that

In Fill (), Dataadpater automatically creates DataReader to fetch data, and then creates

DataTable (equivalent to the data entity Class) and populate the DataTable based on the field type, of course

, if more than one record can be returned, the DataTable is fully processed and there is no need to implement the column

Table operation.

Perhaps the reader immediately raises the question: In this case, why does the petshop need data real

What about the body class?

There are some differences.

First, the data entity class is lightweight structure, typically containing only data fields, without

What is the operational approach, which has some performance advantages over DataTable or DataRow?

(Negligible when the amount of data is small); On the other hand, the operation of the data entity class is relatively

Simple, no need for developers to have any ado.net knowledge (in fact, the DataTable

Said, this is not a problem), click the attribute on it.

However, according to the author's practice, these two aspects do not seem to be enough to make people turn to use

DataReader programme, citing the following reasons:



(1) for the large number of occasions, can be used in batches of reading, which is similar to the DataGrid data paging effect;



(2) For simple data, entity classes can also be dealt with, once the associated data is involved, you can only write a different method. All of these, in the dataset, are very easy to handle (for enterprise applications, most cases need to deal with more complex data);



(3) The DataTable is "born" to support data set operation, which is more easily controlled and more natural than the mixed mode of "SET + entity" (petshop);



(4) Entity classes need to determine all data types when they are declared, and when data is populated, it is necessary for DataReader to pay attention to the corresponding data type of the entity again, without any errors! In this respect, the DataTable is very convenient, the operation requires only one type of attention can be;



(5) The dataset solution can easily support serialization operations (e.g., remoting,webservices), while the relationship with XML is extremely intimate, which is also critical to interacting with other systems.



Analysis of a number of technologies and programs, believe that readers have some experience of friends. At the end of this season, if you have to provide a "summary" here, the author's advice is clear:



In enterprise application development, as far as possible using DataSet (Datatable/dataview) + Cache management solution!



In other developments, the use of DataReader is considered only in the following 4 situations (as far as the author's experience is concerned, most of the use of DataReader is the 2nd):



(1) The resource requirements of the more demanding occasions, where the resources mainly refers to the memory and database connection;



(2) You want custom processing when reading the database to return a result set, such as terminating the processing immediately after reading a record, or doing a calculation while reading.

(Hint: This situation is similar to the SAX in XML (simple API for XML) technology, which does not need to read all the XML data at once; instead, DOM (Document Object Model) requires that all of the XML data must be loaded before the operation can begin (MSXML4.0 has started to allow reading only part of the XML document to begin operations, which is something)!)



(3) Only want to get the number of returned records or return records of some fields, such as:

String Getnamebyid (int NID)//Return employee name based on employee ID, here only

Read the last name paragraph;

(Hint: this situation can generally be solved directly by executing a specific query or stored procedure)



(4) for some aspects of consideration (for example: N-tier system in strict distinction between the responsibilities of each layer), can not (or prohibit) through the database itself for query filtering, then only use DataReader in the reading of the filter operation!

(Hint: Although DataView can achieve this goal, but its filtering premise is must read all return data, so the performance is inferior datareader! ）