In this chapter, I examined techniques and tools for building sophisticated, professional
Reporting does not exhaust the range of functionality provided by Web applications. In Chapter 7, I ll focus on disconnected applications, caching, and batch update.
Disconnected Web Applications
If you ve programmed data-driven applications, disconnected programming is nothing new for you. A few
ADO and ADO.NET are designed differently. ADO was invented in the age of connected, 2-
Typically, the purpose of disconnection is to enable the application to cache data locally and then access the local cache instead of the native storage medium. However, not all applications can
What Is the DataSet Object Really For?
object represents an in-memory cache of data and is the critical object that gets passed between the middle tier and the client application (for example, a Microsoft Windows Forms application) or between the middle-
A Windows Forms application that receives a
object can take full advantage of it. Data is cached on the client and, unless you need a current copy of the data, you can
Implications for Web Applications
object is still great for storing the state that survives across page
Which client processes disconnected data through the DataSet object? The HTML page displayed by the browser is one possible client. The middle-tier component (in the simplest case, an ASP.NET page) that connects to the database is another possible client. If the presentation layer is based on a browser, you cant really send a DataSet object embedded with HTML code. Im sure you could come up with some workarounds, but they wont be exciting prospects until .NET languages are natively supported by Microsoft Internet Explorer .
Disconnection for Web applications means that you cache data on the Web server and keep your middle tier working off line and disconnected from the database server. The advantages of this technique are more relevant if your system architecture provides two distinct server machines for the database and the Web server.
Caching on the Web server is critical, and you have several options to choose from: using the
object (in-process, out-of-process, or SQL Serverbased); the
object; the powerful
object (new to ASP.NET); or the same
object, by performing brute-force serialization of it into the page view state. You can also cache to XML files to avoid taxing the Web servers memory on a per-
The Cache object represents the ASP.NET cache engine that can be used by pages to store and retrieve objects across HTTP requests. This cache is unique for each application and stores objects in memory. The lifetime of the cache coincides with the lifetime of the application. Although the Cache object might seem like the thread-safe version of Application , it provides additional features to ensure that seldom-used data never wastes server resources. If you want to control how scavenging occurs, you can provide the following for each item: expiration dates, decay factors, priority level, key, and file dependencies.
Let me sum up your options. If you plan to use server-side caching, start by choosing a caching mechanism and pay careful attention to the advanced services of the built-in ASP.NET caching service. With regard to the data container object, you probably need to look at only the
object. Whatever caching mechanism you implement, use
to collect data. It is unique in its ability to
DataSet and the DataGrid Control
As mentioned in previous chapters, the use of
can be critical when you use it with certain controls such as the
control. Using it with the
control can be dangerous to the health of your application because the
control does not cache the
object it is bound to. When you return to the Web server for a postback event, you have to reload
and rebind with the
control. At that point, you have two
If you need fresh data, use the more lightweight DataReader object and use custom pagination to minimize the number of records loaded.
If you dont care about fresh data (because your database is not volatile or your users are not interested in last-minute changes), cache the
object. For the majority of applications, the
object is the best place to park data. To make it
Like the Application object, the Cache object does not share its state across a Web farm, so the Web farm scenario is the hardest one for application-wide caching. Relying on the built-in database caching mechanism is probably the most efficient approach. Consider that databases, and SQL Server 2000 in particular, feature very advanced and super-optimized query engines. Queries that execute frequently, such as those used to page back and forth, are recognized and cached internally, so getting fresh results for a small number of rows takes little time. No matter how smart you are, I have a strong feeling that outperforming the cache system of SQL Server 2000 wouldnt be that easy for you!
Towards Disconnected Applications
Applications called to manage data that is not particularly volatile or that has a low degree of decay can happily cache the DataSet object on the Web server. By doing so, these applications can use a DataGrid control to sort and page through the data.
In this chapter, Ill go beyond the basics of data disconnection and focus on a couple of additional aspects that address more general techniques and cover a broad range of applications. One of these techniques is
The application well examine uses a double level of caching. One level is in-memory caching, used to fill out the
control that is showing the data. This kind of caching is implemented by using the
object and is tied to the applications lifetime. A second level of caching keeps the application disconnected from the data source across multiple executions of the application. Basically, you hibernate the state of the application and resume it on the
This hibernation technique is not appropriate for every application. To be really effective, it must rely on a database with a low level of concurrency and a low