Persisting Page State in ASP.NET 2.0

Posted by: 4GuysFromRolla.com Headlines, on 17 Jan 2007 | View original | Bookmarked: 0 time(s)

There are different types of state in an ASP.NET web application: page state, session state, and application state. Page state is state that is specific to a particular user's visit to a particular page and is commonly used to remember any programmatically changed state of the page across postbacks. Session state is state remembered for a particular user across all visits and all pages during their session. Application state is state that is shared across all users on all pages and all requests and is often used for caching data or information that is applicable to all users visiting the site.

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 version 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. We'll also look at how to extend the functionality to provide a custom persistence scheme. Read on to learn more!
Read More >

Category: ASP.NET | Other Posts: View all posts by this blogger | Report as irrelevant | View bloggers stats | Views: 2415 | Hits: 91

Similar Posts

  • "Page" vs "PageData" objects in ASP.NET Web Pages more
  • SQL SERVER PAGELATCH_DT, PAGELATCH_EX, PAGELATCH_KP, PAGELATCH_SH, PAGELATCH_UP Wait Type Day 12 of 28 more
  • SQL SERVER PAGEIOLATCH_DT, PAGEIOLATCH_EX, PAGEIOLATCH_KP, PAGEIOLATCH_SH, PAGEIOLATCH_UP Wait Type Day 9 of 28 more
  • November's Toolbox Column Now Online more
  • Sneak Peak: CSS Sprites Make Your Websites Faster more
  • TIP: How To Generate a Fully Qualified URL in ASP.NET (E.g., http://www.yourserver.com/folder/file.aspx) more
  • ASP.NET 4 Beta 2 - New Version, New Docs, New MSDN Site ! more
  • Creating a Filtering User Interface With jQuery In a Web Forms Application: Part 2 more
  • jQuery UI Datepicker and z-Index more
  • Silverlight 3 Navigation: Even more on Dynamically Loaded Pages more

News Categories

.NET | Agile | Ajax | Architecture | ASP.NET | BizTalk | C# | Certification | Data | DataGrid | DataSet | Debugger | DotNetNuke | Events | GridView | IIS | Indigo | JavaScript | Mobile | Mono | Patterns and Practices | Performance | Podcast | Refactor | Regex | Security | Sharepoint | Silverlight | Smart Client Applications | Software | SQL | VB.NET | Visual Studio | W3 | WCF | WinFx | WPF | WSE | XAML | XLinq | XML | XSD