Programming Microsoft ASP.NET 4 - Dino Esposito [374]
Leaving the view state on the server is definitely possible and all you have to do is override a couple of protected members on the Page class. The devil is in the details, however.
You should guarantee that the correct view-state file will be served to each page instance the user retrieves via the browser’s history. This is not an issue as long as each page contains its own view state. But when the view state is stored elsewhere, unless you want to disable Back/Forward functionality, you should provide a mechanism that serves the “right” view state for the instance of a given page that the user is reclaiming. At a minimum, you need to make copies of the view state for about six to eight instances.
As you can see, what you save in the roundtrip is lost in the server’s memory or server-side I/O operations. All in all, keeping the view state on the client and inside of the page is perhaps the option that works better in the largest number of scenarios. If the view state is a problem, you have only one way out: reducing its size.
Summary
Although HTTP is a stateless protocol, Web applications can’t just do without certain forms of state. Moreover, state management is a hot topic for all real-world Web applications. Setting up an effective and efficient solution for state management is often the difference between an application being scalable or nonscalable.
One of the most-used forms of state is session state—that is, the state specific to a user and the one that’s valid as long as that user works with the application. You can store session data in the memory of the ASP.NET worker process as well as in external processes, and even in a SQL Server table or in a custom state provider. In spite of the radically different options, the top-level programming interface is identical. More importantly, the ASP.NET session state can be persisted in a Web farm or Web garden scenario as well.
In the next chapter, we’ll deal with another extremely powerful form of state container—the Cache object.
It’s worth spending a final word on a form of state management that might grow significantly in the future, especially as HTML 5 becomes widely supported by browsers—client side state. Around the HTML 5 working draft, in fact, a number of technologies are being developed for storing information on the browser in a much more powerful way than with cookies. It ranges from simple forms of isolated storage (already in Internet Explorer 8) to Web SQL databases. As usual, time will tell. And years of experience remind us that no matter how cool it could be, it only works if it is widely supported.
Chapter 18. ASP.NET Caching
Hope is a good breakfast, but it is a bad supper.
—Sir Francis Bacon
Caching indicates the system’s, or the application’s, ability to save frequently used data to an intermediate storage medium. An intermediate storage medium is any support placed in between the application and its primary data source that lets you persist and retrieve data more quickly than with the primary data source. In a typical Web scenario, the canonical intermediate storage medium is the Web server’s memory, whereas the data source is the back-end data management system. Obviously, you can design caching around the requirements and characteristics of each application, thus using as many layers of caching as needed to reach your performance goals. In ASP.NET, caching comes in two independent but not exclusive flavors: caching application data, and caching the output of served pages.
To build an application-specific caching subsystem, you use the caching application programming interface (API) that lets you store data in a global, system-managed object—the Cache object. This approach gives you the greatest flexibility, but you need to learn a few usage patterns to stay on the safe side.
Page-output caching, instead, is a very quick way to take advantage of cache capabilities. You don’t need to write code; you just configure it at design time and go. The ASP.NET system takes care of caching the output of the page to serve