Maintain List<> state across page boundaries in ASP.Net

Question

I have an ASP.NET WebForms application that has a feature that requires the user to provide data in multiple steps. This is currently implemented using multiple pages. So, the user visits step1.aspx, provides some information, and then is redirected to step2.aspx to provider additional information.

The objects that are manipulated as part of this process are stored in a generic List<> object. I'm currently storing this List<> in a Session variable so that the state of the objects is maintained between pages. Once the process is complete the data is sent to a web service api exposed by another application. I don't want to maintain the state of this data in a database between posts, preferring to keep it in memory until it gets submitted to the web service.

I'm in the process of extracting this logic out of the web application into it's own class library so we can use the same library from a windows application.

What are the best practices for maintaining this data between posts after extracting the business logic to a self-contained class library?

Answer 1

I would suggest that you derive your business logic into two class, one for consumption by web forms and one for consumption by windows forms. You've already written standard sessioning code why let it go to waste?

If you have your heart set on only creating a single class I suppose you check the type of object that calls it to define your logic.

Answer 2

With ASP.NET, you have a few options. You could store it in session state, but that quickly becomes a problem because of multiple browser windows in the same session.

That leaves passing the data input on one page from page to page.

You could encode the data in the query string and append it to the URL, but depending on the size of the data, that could get pretty long and unwieldy.

That leaves posting the data. You can start with the first form and have it post to the second form. The second form encodes the data from the first form in a hidden field, and then passes it's data and the hidden field data to the next form, etc, etc.

Then, on the page after the last form (that processes everything) you have all of your data for the separate steps.

Answer 3

If you want to have the library responsible for managing it's own state you could use a IoC pattern and inject a class which will handle the state for the data. So for example imagine you have:

class MyWizardLogic
{
 public void DoStep1()
 {
 }
}

Now we can define a new interface call it a StateProvider because it provides state:

interface IStateProvider
{ 
   List<WizState> CurrentState{get;set;}
}

Now what you need to do is to tell the MyWizardLogic to use IStateProvider there are lots of choices if you want to use a DI framework but lets keep this simple. You can create a SessionStateProvider class which will store the List to session. And you could create a second WinFormsStateProvider class which will store the List in a static variable or some other appropiate place.

I would create these class in their respective projects. These class shouldn't be part of the BL library.

Now you can modify your DoStep1() method to take a parameter of IStateProvider. This will let your web or winform app specify which IStateProvider to use. Additionally you could set it via a property or in the constructor. I prefer using a constructor typically.

Now your all set for your client to control the BL dependancies. This should also help make testing easier. For example you could write a mock state provider which validates that it is being called correctly.

Answer 4

You can put your multiple steps into one page and use an ASP:MultiView to manage the various steps. In fact, the MultiView has a template type called asp:WizardStep. This way, you can maintain state between steps in the pages ViewState and eliminate the need for Session variables.

MSDN has some great info and examples here.