title: ASP.NET MVC: Best practices for keeping session state in a wizard-like app
body: <p>Let's say I have a Web application implemented like a set of wizard pages to edit a complex object. Until the user clicks on the "Finish" button, the object doesn't get saved to the back-end system (a requirement), so in the meantime I have to keep the whole information about the object in some kind of a session state.</p>
  
  <p>Also, some of the wizard pages have to show combo and list boxes with potentially large number of items. These items are fetched from the back-end system using a Web service.</p>
  
  <p>Coincidentally, the wizard allows the user to freely jump from one wizard page to any other (using tab links on top of the form), so it's not a simple "next, next... finish" thing.</p>
  
  <p>Additional constraint: the Web application runs on a Web farm and the customer is weary of using server-side session state. In the best case they want to keep the size of the session state minimal (they had problems with this in the past).</p>
  
  <p>So basically there are two problems here:</p>
  
  <ol>
  <li>How/where to keep data entered by the user in the Wizard?</li>
  <li>Whether to cache the combo/list items received from the back-end and if so, where?</li>
  </ol>
  
  <p>Options I'm considering:</p>
  
  <ol>
  <li><p>Storing the object in a WebForms-like <strong>ViewState</strong> (by serializing it into the HTML page). This would also include the combo box items. Obviously, there could be a problem with HTML pages becoming very large and thus Web application will be slow.</p></li>
  <li><p>Storing it into <strong>server-side session state</strong>, regardless of the customer's wishes and without knowing how the performance will be affected until it is tested on the actual Web farm (late in the project).</p></li>
  </ol>
  
  <p>I cannot decide between the two. Or is there another alternative?</p>