Data and State Management


Your users can now select a slideshow; what we need is a page to display the slides for the selected slideshow. You created a slideshow page in Chapter 5 that has all the basic functions you need displaying slides and allowing users to navigate between slides. However, you ll be working with slide information in a new way here. In Chapter 5, the slide information was in an array, but in the new slideshow page, the slide information will come from the database. The slideshow page will still have a structure for storing slide information, but its structure will be different from the array in Chapter 5.

Understanding Datasets

As in the first slideshow page you created in Chapter 5, this slideshow page needs to keep a list of the slides to work with. Having a list allows you to perform navigation by moving forward or backward in the list. The list also allows you to count the number of slides so that you can display a slide count in the page and check for wraparound (proceeding from the last slide back to the first) during navigation.

When you re working with database tables in a Web page and need to keep them in a list-like structure, you use an object called a dataset. A dataset is an object in memory that acts as a container for data from one or more database tables, as shown in Figure 12-4. To use a dataset, you create a new dataset object and then use the normal data objects connection, command, and data reader to execute a SQL statement and read the results into the dataset. Once the dataset is loaded, you can get individual records out of the dataset in a way that s (almost) like getting them out of an array.

click to expand
Figure 12-4: A dataset holds a copy of database data in memory in a list-like structure.

Fortunately, Web Matrix can generate most of the code you need to load the dataset. You ll just need to create the dataset, call the Web Matrix code to load it, and then create page code that works with a dataset instead of an array.

Caching Data in the Session Object

We have one more issue to deal with, however. At the risk of repeating myself, I ll remind you that every time the page makes a round trip, the page is re-created from scratch. If your page creates a dataset and loads it, that could mean re-creating the dataset and reloading it (thereby executing a SQL statement) each time the user clicks the Previous or Next button to navigate to another slide. Executing a database query every time the user moves to another slide would be inefficient.

The solution for this potential inefficiency, as you might guess, is to store the dataset someplace so that it doesn t have to be re-created with each round trip more state management! In previous chapters, you stored information between round trips using viewstate (the slide number in Chapter 5), cookies (user preferences in Chapter 6), and in the Application object (the quotations file in Chapter 7). None of these options is quite right for a dataset. A dataset can be quite big, so it s not a good idea to store it in viewstate remember that viewstate is stored in the page itself and has to go to the browser and back to the server. A cookie is too small to accommodate a dataset. Application state is global for all the users of your application, whereas each user might be viewing a different list of slides.

You ll therefore use a Session object. A Session object is similar to an Application object. As with an Application object, ASP.NET maintains a Session object between round trips, and you add and read values in the Session object the same way you work with the Application object. Unlike the Application object, however, the Session object is private to each user. Each user and browser has its own separate session with the server, so if multiple users are working with the application at the same time, they won t clobber each other s stored values. The Session object is therefore a good candidate for storing a dataset that you want to maintain between round trips. (The Session object has some limitations; see the following sidebar.)

start sidebar
More on the Session Object

The Session object is similar to an array in that it can contain multiple objects. However, rather than maintain them as an ordered list that you access using an index value, the Session object stores values by name.

In ASP.NET, Session objects have an inherent problem. Values that you store in a Session object take up memory on the server. In addition, don t forget that each user has a separate Session object that s private to that user, and multiple Session objects can eat up a lot of memory on the Web server. But given that the Web is disconnected, how does ASP.NET know when any given user has finished with his or her Session object? Basically, ASP.NET can t tell when users have finished. For example, you might have played with your Web application for a while, which stored values in a Session object, but then you might have surfed to another site to read the latest sports scores, leaving the Web server holding the Session object in memory. To address this problem, ASP.NET puts a timer on Session objects. If a Session object has been idle for 20 minutes, ASP.NET discards it. Under some circumstances, having an idle Session object time out after 20 minutes could be a problem, but in practice, it rarely is. In the slideshow example, a Session object timeout will occur only if a user waits 20 minutes before clicking a navigation button. (If users do wait more than 20 minutes and the session times out, users will get an error message.) Sessions are also discarded if users close their browsers.

end sidebar



Microsoft ASP. NET Web Matrix Starter Kit
Microsoft ASP.NET Web Matrix Starter Kit (Bpg-Other)
ISBN: 0735618569
EAN: 2147483647
Year: 2003
Pages: 169
Authors: Mike Pope
BUY ON AMAZON

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net