.NET news » ASP.NET

Most Design Pattern documentation targets desktop applications or discusses pattern theory, but in this series you'll find a discussion and examples of patterns specifically targeted at ASP.NET.

The fiinal tutorial on master/detail reports. We'll look at how to display a list of products in a GridView where each row has a Select button. Clicking the Select button will display that product's details in a DetailsView control on the same page.

While master/detail reports can display both the master and detail records on a single page, on many Web sites they are separated out across two Web pages. In this tutorial we looked at how to implement such a master/detail report.

The DropDownList serves as an ideal user interface element for master/detail reports where there is a one-to-many relationship between the master and detail records.

A common type of report is the master/detail report, in which the report begins by showing some set of "master" records. The user can then drill down into one of the master records, thereby viewing that master record's "details." Master/detail reports are an ideal choice for visualizing one-to-many relationships, such as a report showing all of the categories and then allowing a user to select a particular category and display its associated products. Additionally, master/detail reports are useful for displaying detailed information from particularly "wide" tables (ones that have a lot of columns). For example, the "master" level of a master/detail report might show just the product name and unit price of the products in the database, and drilling down into a particular product would show the additional product fields (category, supplier, quantity per unit, and so on).

There are many ways with which a master/detail report can be implemented. Over this and the next three tutorials we'll look at a variety of master/detail reports. In this tutorial we'll see how to display the master records in a DropDownList control and the details of the selected list item in a GridView. In particular, this tutorial's master/detail report will list category and product information.

Explains how to send e-mail from ASP.NET, including sending of simple e-mail, adding attachment, HTML e-mails and how to avoid potentially dangerous request errors.

Explore ways to reduce page load time, manage state efficiently, scale back on memory use, handle resources better, and improve data access in your ASP.NET applications.

Page state, commonly referred to as view state, is persisted in a hidden form field, by default. When a page is being rendered, any programmatic changes to a control's state is saved to the page's overall view state. During the rendering stage, this view state is serialized into a base-64 encoded hidden form field and sent down to the client's browser. On postback, the view state data is sent back to the web server, where it is deserialized and returned to the appropriate Web controls in control hierarchy so that they may re-establish their state as it was prior to the postback.

View state provides a slick way to remember state in a stateless client-server model and it happens underneath the covers without any extra effort from page developers. The downside of view state, however, is that in certain situations the view state can grow to be exceedingly large. A large view state requires a longer page download time since it bloats the total web page size and also affects the postback time, since the entire view state content must be posted back to the web server along with the other form fields.

It is possible, however, to persist view state to an alternate medium. Such customizations were possible in ASP.NET 1.x by overriding a couple of methods in the Page class. ASP.NET 2.0 makes customizing page state persistence easier as this logic is handled through a separate class. In this article we'll explore the built-in page state persistence options in ASP.NET 2.0, which includes the ability to persist page state to session state rather than through a hidden form field.

By adding configuration design support, you can make your custom providers look and feel just like the built-in providers, letting users select them and provide settings through the Configuration Console.

One of the most sure-fire ways to improve a web application's performance is to employ caching. Caching takes some expensive operation and stores its results in a quickly accessible location. ASP.NET version 1.0 introduced two flavors of caching:

• Output Caching - caches the entire rendered markup of an ASP.NET web page or User Control for a specified duration.
• Data Caching - a programmatically-accessible, in-memory data cache for storing objects in the web server's memory.

For a more in-depth discussion on ASP.NET 1.x's caching capabilities, refer to Scott McFarland's Caching with ASP.NET and Steve Smith's ASP.NET Caching: Techniques and Best Practices articles.

In ASP.NET 2.0, the caching system has been extended to include SQL cache dependencies, cache profiles, and post-cache substitution for output cached pages. The Caching for Performance section of the ASP.NET 2.0 QuickStarts provides a good overview of ASP.NET 2.0's caching options. This article explores output caching in ASP.NET 2.0, starting with an overview of output caching and followed by a detailed look at creating pages that include both cached and non-cached markup using fragment caching and post-cache substitution techniques.