For example, imagine you're writing some sort of shopping portal. Certain types of the application data can be kept in a central database-things like inventory and supplier lists. We've seen that System.Web.UI.Page and server-side controls themselves manage view state. However, when you think about the nature of data in a user's shopping cart, you see the data clearly belongs elsewhere.
You don't really want to store that data in the page's ViewState. While it's possible for simple applications, storing large chunks of data in view state will bog down your users' experience of the site (it'll be much slower) and it poses a security risk by having items travel back and forth with each request. In addition, only serializable types may be stored in view state.
Unfortunately, a single user's data doesn't really belong in the central database, either. Perhaps if you expected only one user over the lifetime of your application, that might work. However, remember the nature of a Web application is to make your application available to as many clients as possible. Suddenly, it becomes clear that you want to be able to carve out a small data holding area that persists for the lifetime of a single user's session. This type of data is known as session state.