Just the Facts

• Compared to the intrinsic Session object of classic ASP, the ASP.NET session state is nearly identical in use, but it's significantly richer in functionality and radically different in architecture.

• As of ASP.NET 2.0, there are four possibilities for working with the session state. The session state can be stored locally in the ASP.NET worker process; the session state can be maintained in a remote process; the session state can be managed by SQL Server and stored in an ad hoc database table. Finally, a fourth option is added in ASP.NET 2.0 and allows you to store the sessions in a custom component.

• In ASP.NET 2.0, the session-state subsystem was refactored to allow developers to replace most of the bits and pieces of functionality a characteristic that is often referred to as session-state pluggability.

• By default, the view state is enabled for all server controls; however, this doesn't mean that you absolutely need it all the time and for all controls. The use of the view-state feature should be carefully monitored because it can hinder your code and unduly bloat your pages.

• In ASP.NET 2.0, the size of the view state is significantly reduced as a result of a new binary serialization format.

• The contents of the view state have been split into two states: classic view state and control state. Unlike the classic view state, the control state can't be disabled programmatically and is considered a sort of private view state for a control.