This topic has not yet been rated - Rate this topic

Introduction to Data Access in Web Forms Pages

Visual Studio .NET 2003

Web Forms pages often need to display information that derives from a database, an XML document or stream, or some other data source. The architecture of Web Forms pages provides you with ways to incorporate data sources (or references to them) in the page, to bind controls to data, and to manipulate data in various ways.

However, due to the nature of not just Web Forms pages, but of Web programming itself, data access in Web Forms pages differs in several ways from data access in Windows Forms or in forms technology of previous Microsoft products. To some extent, these are the same differences that make any kind of Web programming different from traditional forms programming: state management, separation of server and client, designing for scalability, and so on. In addition, because you are working with other resources such as databases, there are important points to understand about how to manage data in Web Forms pages.

Note When you deploy an application that includes Visual Studio data-access components, you must make sure that the user installing the application has version 2.6 or higher of the Microsoft Data Access Components (MDAC). For more information, see Adding a Launch Condition for Microsoft Data Access Components.

Fundamentals of Data Access in Web Forms Pages

Data access in Web Forms pages is built around the following fundamental principles:

Using a disconnected model
Reading data more often than updating it
Minimizing server resource requirements
Accessing data using remote processes (distributing data access)

Disconnected Model

Web Forms pages are disconnected. Each time a Web Forms page is requested, it is built, processed, sent to the browser, and discarded from server memory. By extension, the same applies to data access in a Web Forms page. Data is read or updated while the page is being processed on the server; when the page is finished and sent to the browser, data is discarded along with other page elements.

This model has various implications for how you work with data in the Web Forms page:

The data you are working with is not automatically available for each round trip — that is, when users click a button in the page. If you want to access the data again each time the page is posted to the server, you must either re-read the data from the source with each round trip or you must include code in the page to explicitly save it and restore it as part of page processing.
It is impractical to maintain open connections to data sources. Generally, during page processing you open a connection to the source, read or write data, and then close the connection.
During each round trip, you typically perform a single data access operation. For example, the first time the page is called, you might read data from the source and bind controls on the page to it. When users click a button, you might write data from a control back to a data source. If you are implementing operations such as paging in a grid, each round trip typically fetches one set of records.

Reading and Updating Data

The Web Forms data model presumes that most data access by Web pages is read-only. Typical examples are catalog or search listings, which display data items. (The items are often links to other pages.) In most cases, the user does not enter data that is written back to the data source.

Because most data access is read-only, the Web Forms data-binding architecture is one-way. That is, data binding displays data in controls, but does not write data from the controls to a data source.

One-way data binding makes Web Forms pages more efficient. Updating requires substantially more overhead in a page: the page must have available copies of the records to update and must include logic to update, insert, and delete records. Because this overhead can add significantly to the page processing time and to server memory requirements, and because in most pages no updates are required, the default for Web Forms pages is not to include a way to write data from a control to a data source.

If you are creating a page that updates a data source, you can include the logic yourself to perform the update operations. For example, a portal page might allow users to specify custom display options. You can use a Web Forms page to present available options and then write the user's options to a database. For details about updating, see Dataset Updates in Visual Studio .NET. For an example of how to perform updates, see Walkthrough: Updating Data Using a Database Update Query in Web Forms.

Minimizing Use of Server Resources

Because Web Forms pages are processed on the server before being sent to the browser, any data access in the page adds to the server load in both processing time and memory usage. If you choose to save data between round trips and you keep it on the server, you use server resources even when the page is not being processed.

Data access in Web Forms pages therefore requires careful attention to how you are using resources. A data–access design that uses server memory or processing time unnecessarily might work for a few users of your Web application, but can become unwieldy as your application scales up to many users. Examples of some of the design decisions you might make include:

Get only as much data from a data source as you need in any given page.
Use client-side state management options (for example, view state) to store data if possible.

For more details about designing data access for Web Forms pages, see Web Data Access Strategy Recommendations.

Data Access in Remote Processes

Web Forms pages are the presentation tier of your Web application. You can build data access into your pages, but it is also common to separate data access logic from the UI by building it into another component (for example, an XML Web service) that interacts with the data source. For more information, see Introduction to ASP.NET Web Applications in Visual Studio.

As .NET components, Web Forms pages exchange data with other processes via an XML stream. You generally do not need to work directly with the XML being passed between components. The data framework of your page (usually a dataset) performs this conversion automatically. However, if it makes sense in your application to do so, you can access data in XML format directly.

Access Permissions for Web Applications

Regardless of the specific data-access strategy you select for your application, you need to be aware of the security implications of data access. In most cases, data resources are protected by Windows or database-specific security. When you create data access in your application, you need to be sure that the application will have sufficient permissions at run time to get access to the data it needs. (The permissions that your application has at run time are often different from the access you have at design time while creating and testing your application.)

For details, see Access Permissions for Web Applications. For details about accessing SQL Server, see Accessing SQL Server from a Web Application.