title: Entity framework - storing various types
body: <p>I'm building a workflow for some forms, that would route to users for approval.  I have an abstract 'FormBase' class which stores a LinkedList of 'Approver' objects and has some helpers that modify the approver list, move the form to the next person and so on.  These helpers are all 'virtual' so that a given form can override them with custom behaviours.</p>
  
  <p>From this 'base' will come instances of various forms, each of which will differ in the data it contains.  It'll be the normal set of lists, strings, and numeric values you'd find in a normal form.  So I might have</p>
  
  <pre><code> class MaterialForm : FormBase
   class CustomerForm : FormBase
  </code></pre>
  
  <p>etc, and a new instance is created when a user creates and submits a form.</p>
  
  <p>I'd like to persist the field details of in EF6 (or 5), in a flexible way so I could create more forms deriving from FormBase without too much fiddling.  Ideally I'd like all behaviour specific to that form type to live in the MaterialForm derived class.  I figure I can't persist this derived class to EF (unless I'm wrong!).  I'm considering:</p>
  
  <p>a) JSonifying the field details, and storing them as a string in the class which gets stored to EF.  I'd probably do the same for the approver list, and each time I need to modify the list I'd pull them out, modify the list and push them back.</p>
  
  <p>b) Including a 'FormData' property in my abstract class, then including a derived version of that in each concrete implementation (eg MaterialFormData, CustomerFormData).  However, the abstract class didn't seem to like my use of a derived type in this way.  Also unclear is how the DbSets would be setup in this case as you'd probably need a new table for each type.</p>
  
  <p>I feel I'm misunderstanding something fundamental about how the 'real' classes relate to those stored in EF.  What would you recommend as an architecture for this case?</p>