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.
- 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.
- 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.
- 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?