0

I have a ASP.NET application which puts the users through a series of forms in a wizard like fashion and has them fill out fields on the form. In code, these forms and fields are represented as "Step" objects, with a collection of "Field" objects as properties.

Currently I have only one Step class, and each individual step is an instantiation of this class with various identifying properties set on it, including the collection of fields. The step objects are persisted in a database and loaded using an ORM. Note these "Step" objects aren't actually responsible for tracking progress of a specific user, they're really just templates that describe step properties like name, display name, step order, etc. Progress is tracked through a series of "ItemStep" objects which basically link one of these "Step" templates to a specific "Project". "ItemSteps" store information about which steps are completed, locked, skipped, etc.

However, these step objects and the associated field objects are not designed to be configured by end users. Most changes to the objects would likely break the application without corresponding changes to the code. Given all of this, I see 3 possible things I can do.

  1. Moving the steps and fields out of the database and into some sort of in memory collection. My basic thought process is to have a static collection that holds all the steps, which will be hidden behind my existing data access logic.
  2. Create a new class for each step, and appropriately define equality methods so that two step objects of the same class are considered equal. Then instead of querying either my in memory repository, or my ORM, all I need to do is new up an instance of the appropriate step class. The only downside is I have to find some way to persist the relationship between an "ItemStep" in the database and the "Step" class it should be instantiated with.
  3. Do nothing and keep everything as it is.

I figure 1 or 2 will result in a performance improvement since they'll be fewer trips to the database, and will streamline the process of application changes, since I won't have to worry about updating the database. And either 1 or 2 could also make it easier to build out a rich inheritance model around the steps, and move some logic onto the step class itself, instead of where it currently sits, inside my Presenters.

Of these three possible solutions, what would you reccommend?

Improve this question
5
  • I guess my first question back would be: Why were these steps in the database in the first place? There must have been a reason, at some point. Is that reason no longer valid? Commented Jan 25, 2013 at 18:31
  • Honestly, there isn't a compelling reason. When I originally built the application I envisioned something more flexible that would allow for the kind of configuration where users could edit steps and forms on their own, but that hasn't turned out to be a relevant use case. Also, my skills as a developer have matured significantly since this project started, and in my initial design I mostly just assumed this data should be persisted without really recognizing that there were alternatives. Commented Jan 25, 2013 at 18:35
  • Does it matter if you lose progress if/when the server dies during a user's form/session? Writing to a db will allow them to recover, in memory will potentially lose it all. Commented Jan 25, 2013 at 19:38
  • @SnOrfus: I think OP is talking about storing the wizard "templates" in the DB not the contents of a specific user's session. I think in this case, there's not much to be gained by storing in the database. Keeping the data in an XML configuration might offer a little more flexibility and might make it easier to load the wizards. Caching them in memory after they're loaded is also probably a good idea. Commented Jan 25, 2013 at 19:42
  • Progress isn't tracked against the "Step" object, it's tracked against the "ItemStep". The step object basically represents what steps are available for all projects, while the itemsteps represent the actual steps being used on a given on a specific project, and what their status is. ItemSteps are persisted to the database and that won't change. Commented Jan 25, 2013 at 19:46

1 Answer 1

Reset to default
1

I would recommend using a Cache framework to load the Step info from the database into memory upon the first usage. Every other user should get the result from the Cache framework (memory) instead of it pulling from the database. The Cache can be set to refresh itself every so often if you think this data will be changed from time to time (ex: once per week). If you never expect the data to be changed, then you can turn the refresh off and only have it refresh when the server is restarted. You can build all this yourself, but there are plenty of good cache frameworks out there already.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.