2

I have some questions here and here the management of state in an ASP.NET MVC3 application. One of the answers mentions that an option for this is to simply store the state of each step in the database.

I was wondering if anyone had any advice on how this is usually achieved as I had some thoughts when this was first suggested to me.

Invalid entities

Consider a multi-step form (wizard) that has 3 steps. I could save each step in the database to maintain state but a user could close the web application midway through the process leaving my database containing entities that are in an invalid state.

To overcome this I could add a field to the table which indicates if the wizard has been completed. Any inconsistent items could be reviewed on a periodic basis and automatically deleted if required e.g. if any invalid entities are found in the database at the end of the day they will be automatically deleted.

The problem with this is that I have to add fields to the tables to store metadata about the application. Every table that stores information that is entered in a multi-step form needs to have these fields. This seems wrong to me somehow. One solution might be to create a specific table for managing this rather than polluting each entity table with metadata.

Intermediary database

I thought of having a database that sits in between my application and the 'real' database. The intermediary database would have tables that stored the state information for each 'step' and only when the last step was completed would this information be transferred over to the 'real' database (and the temporary data deleted from the intermediary).

This also sounds similar to one of the session state options offered by ASP.NET already so personally I think this would be a waste of time.

Use in other application (E.G. Desktop)

At this moment in time my application is purely web based, but I have plans for having desktop programs that can interact with the same database. If the database has a load of meta-data used by the web application for storing state my desktop application is going to need to be aware of this in order to avoid any errors (I.E. my desktop application would need to know that it has to set an entity state as 'valid' so that the web application does not delete the entity at the end of the day because it thinks it is invalid).

Summary

So does anyone have any information or tips on how to best use a database for storing application state?

  • Is the database option that common?
  • Is it suitable for large applications with a lot of entities?
  • Are there any performance implications?

Edit

Just to be clear, I am aware that other options exist for managing state in an ASP.NET MVC application (TempData, cache and session) but I am specifically interested in information about using a database to manage state.

Please refrain from down-voting anyone that has mentioned the other options as my original question may not have been clear about this.

Community
  • 1
  • 1
Benjamin Gale
  • 12,977
  • 6
  • 62
  • 100

2 Answers2

1

Why not store data in a session state? You just need to come up with a mechanism that would allow you to uniquely identify and store items in the session state.

To start with, you can use InProc session state mode. As the system grows, you can look into storing your session state on a state server or on a SQL server.

  • I had been considering using session state as it offers me the functionality I require but all sources I have found so far mention that the performance can be poor. I haven't totally written off session state yet but wanted to weigh against the pro's and cons of using the database method. – Benjamin Gale Sep 05 '12 at 14:10
  • 1
    Why would the performance be poor? This is just a wild guess. It all depends on an infrastructure you are running in and a load that you are running under. If performance issues arise, then you can always address them. Using SQLServer for storing session state is equivalent to using the "database method", advantage is that you get a bulk of functionality out of the box. –  Sep 05 '12 at 14:38
  • +1 - I was thinking exactly the same thing. I spent some time this morning looking for some data to support the claims that session state was slow but didn't really find anything. I had also already considered that the intermediary database option was basically the same as using session state with a SQL server database. – Benjamin Gale Sep 05 '12 at 15:58
0

This is a hard one to answer, but basically, I'd see two routes.

If the data in a given step in the wizard is logically right, and meets all the constraints you've imposed, you could write it to your "main" database. For instance, if you've got a multi-step process for managing orders, and step one is to create a customer record if one doesn't already exist, write the customer record to the database when the user completes the form.

This means that if the user goes away, closes the browser or whatever, the data will be there when they come back - which is probably what they expect.

If the data in a given step is NOT coherent, does not meet constraints etc., use session state to manage it until it's ready for writing to the database. Session state in MVC is a bit of a pain, and you should use it sparingly - it makes it hard to write unit tests.

The purpose of session state is to store data that is relevant to the user session, but that isn't (yet) intended to go into the database.

Community
  • 1
  • 1
Neville Kuyt
  • 29,247
  • 1
  • 37
  • 52