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 (không thực tế) 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 (perhaps in conjunction with storing a user ID in a cookie).
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.
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.