Analysis of Data Access Control in ASP. NET 2.0 (1)

Introduction

Data access has always been a key issue in developing Web applications. Almost every commercial application requires a data-driven Web page. Since data access is so common, it is meaningless for developers to repeatedly generate complex code for simple database tasks. Developers need to quickly access data from different data sources with different formats. Fortunately, the newly added Data Access Control in ASP. NET 2.0 and ADO. NET 2.0 solve this problem.
For traditional ASP and ASP. NET 1.1 applications, developers have to create code to access and update databases, and convert the Retrieved Data to HTML format recognized by browsers. Although the Visual Studio. NET wizard can help complete this task, to complete advanced features such as paging and sorting, you still need to perform complex synchronization between the back-end code and front-end display. Generally, such code is difficult to maintain and synchronize, especially when the database is changed or additional data needs to be displayed on the page. In addition, as data storage, XML requires a large amount of code mixed with data access logic.
To improve developers' development efficiency and Web application performance, ASP. NET 2.0 allows you to more flexibly control data by using the encapsulated functions in the new data control, thus reducing the Code required to access and display data. From traditional databases to XML data storage, various data sources can be connected to these controls. All data sources are processed in similar formats, greatly reducing the complexity of developing data-driven applications.

ASP. NET 2.0 requires extensive architectural improvements to support these features internally. The newly added data source object adds a very reliable infrastructure through industry-recognized best practices. Currently, most complex applications can use the data access tools provided by ASP. NET 2.0. The issue of binding and caching ASP. NET 1.x execution is restricted in the architecture and mechanism, which has been solved in ASP. NET 2.0.
Web Application Data Access
In. NET Framework, you can use the ADO. net api to perform data access. The API provides an abstraction layer to encapsulate and hide the details of direct access to the database. These details are sometimes messy. ASP. NET 2.0 Web applications provide some services in ADO.. NET. These services are used to automatically generate connections to various types of data, bind user controls with data, and reduce the amount of code required for developing Web applications that recognize data.
Data Access Architecture
For Web applications in. NET Framework, data access depends on two independent architecture layers. The first layer consists of the framework components required for data access. The second layer consists of APIs and controls that provide data access for programmers. From a practical point of view, you only need to know whether a matching data provider can be found for a specific data source.
Data access involves four main components: Web application (ASP. NET), data layer (ADO. NET ),Data ProviderAnd real data sources. The relationships between these components constitute the infrastructure for all data identification Web applications.

Figure 1. Component Architecture

Data Storage
Data storage starts at the bottom of the stack and provides the basis for the entire data access architecture. Through ADO. NET 2.0, ASP. NET 2.0, Web applications can access data in a variety of data storage, including relational databases, XML files, Web Services, and flat files, or data in a spreadsheet program such as Microsoft Excel. In fact, the real data source has little to do with the mechanism used to read and operate data.
Data Provider
Due to its provisioning model, ADO. NET uses a group of classes and commands to interact with different data sources. The provider provides storage and retrieval functions for a specific data source by defining a set of interfaces and class hooks. The flexibility of this model allows developers to access multiple types of data by writing a set of data access code using ADO. NET.
In ASP. NET 2.0, apart from basic data access, the provider model is actually used for a variety of different tasks. For example, when new personalized features are used to store user data, they depend on several types of providers. Therefore, the actual provider structure is functional dependent. The purpose of a member provider is different from that of a data access provider.
The following table shows the four core objects that comprise the ADO. NET data provider:

Table 1. Core object of An ADO. NET data provider

Object	Description
Connection	Establish a connection to a specified resource
Command	Execute commands on a data source. PublicParameters, InConnectionOfTransactionExecuted within the specified range.
DataReader	Reads read-only data streams from a data source.
DataAdapter	Fill in oneDataSetTo update the parsing data source.

The provider model clearly isolates various usage scenarios. ASP. NET developers can focus on building functional, application human engineering user interfaces, while backend developers can achieve complex integration through existing enterprise-level data storage. Developing Web applications using the ASP. NET 2.0 provider model is an excellent choice.
ADO. NET API
The abstraction layer defined by the ADO. net api makes all data sources look the same. Regardless of the data source, the process of extracting information involves the same key classes and steps. We will introduce the processing process of ADO. NET in the next section.
Web Application Layer
ASP. NET provides a series of controls at the top of the stack. These controls are designed to reduce the number of data access codes developed. For example, developers can use the data source Wizard to automatically create and configure a data source to publish query and retrieval results. In addition, different controls can be bound to a data source. Therefore, controls can automatically set the appearance and content of controls based on the information retrieved from the data source.
These controls have various shapes and sizes, including grids, trees, menus, and lists. Data Binding Control PerformanceidProperty is connected to a data source, which is declared at design or runtime.
Data source controls are bound to lower-layer data storage by providers such as those in ADO. NET. The advantage of using the data source control is that it can be declared on the page. In addition, you can directly use functions such as paging, sorting, and update without writing a line of code.