Best Way to Manage State When Spread has Large Data - Part I

State management has been a very important aspect of ASP.NET application development. Being an ASP.NET control ComponentOne Spread for ASP.NET also supports different processes of managing state. With Spread, we can primarily manage state with the following processes: 1. Saving Data to ViewState. 2. Saving Data to Session State. 3. Saving Data to SQL Database. 4. Loading data for each Page Request. Each of this process of maintaining state has it's own advantages and disadvantages. I will talk about each of these one by one: 1. Saving Data to ViewState** Saving data to ViewSate is suitable when you are dealing with small data. In this process, the state is managed at client side and it requires no access to server resources. Also, all the changes made to Spread are automatically saved to Spread's Data Model. To enable ViewState for ComponentOne Spread all you need to do it to set IsTrackingViewState** property to "True" e.g.

FpSpread1.ActiveSheetView.IsTrackingViewState = true;  

On the other hand, if the data set contains large data then this process is not suggested. Because it increases the size of the saved state on each request made by client. Thereby, it increases the saving and loading time. Saving data to ViewState is not a secure process so we avoid using this technique while using the sensitive data. 2. Saving Data to Session State** Saving the state to Session is the most common way of maintaining state. It is a server side process which makes it easier to implement. By default session values are stored in memory on web server. Session variables stay alive during IIS restarts so the data saved in session state remains there. It also enhance the platform scalability as this process of maintaining state can be used with multiple-computer and multiple-process configurations. With ComponentOne Spread you can simply handle the Session object in SaveOrLoadSheetState** event. This event is fired when the sheet's data is saved or loaded to ViewState:

protected void FpSpread1_SaveOrLoadSheetState(object sender, FarPoint.Web.Spread.SheetViewStateEventArgs e)  
{  
  if (e.IsSave)  
   {  
     Session[e.SheetView.SheetName] = e.SheetView.SaveViewState();  
   }  
  else  
   {  
     e.SheetView.LoadViewState(Session[e.SheetView.SheetName]);  
   }  
  e.Handled = true;  
}  

A disadvantage of using Session state is that the session variables remain in the memory until they are explicitly removed or replaced. Also Session state does not persist across ASP.NET application boundaries. If a browser navigates to another application, the session information is not available to the new application. We will discuss about other options of maintaining state in my next blog. Please fell free to ask any questions related to the above post. Sample Application http://www.componentone.com/SuperProducts/SpreadWeb/