title: c# parsing and type conversion in a property getter/setter
body: <p>I have been constantly revising my code on the best method for me to handle inheritance with a single table db structure using entity framework. By single table i mean there is a column for each property of the core object and all inherited properties are stored as a json object in a column called params. This object will represent the DB structure.</p>
  
  <pre><code>public class Parent
  {
      public string Name {get; set;}
      public DateTime Created {get; set;}
      protected ExpandoObject Params {get; set;}
      public TypeEnum Type {get; set;}
  }
  </code></pre>
  
  <p>I pull 1 parent from the DB and i do not know its type. I need to first parse it to a Parent object and then read the Type property to figure out what it is. From here i can cast it to its correct type. I have tried so many ways to handle this and i think i have come up with the cleanest possible way, but it results in having to put some parsing and data conversion in the getters. Here is an example.</p>
  
  <pre><code>public class Child : Parent
  {
      public int ChildID{
          get {
              return Convert.ToInt32(this.Params.ChildID);
          }
          set {
              this.Params.ChildID = value;
          }
      }
  
      public SomeEnum SomeOtherType{
          get {
              return (SomeEnum)Convert.ToInt32(this.Params.SomeOtherType);
          }
          set {
              this.Params.SomeOtherType = value;
          }
      }
  }
  </code></pre>
  
  <p>This to me is super clean as it hides the complexity of the implementation while also allowing me to easily cast Child to Parent without a loss of data. The issue i am seeing is that integers are being stored as a long and i need to convert them to be an int (it never needs to be a long). For enums it does the same. Is this kind of data handling acceptable to have in a getter of an object? The main drawback i see here is that the parse needs to be done every single time the property is called, but it isnt too expensive. If this is terrible practice, how should i be doing this?</p>
  
  <p>The alternatives i have already considered are </p>
  
  <ol>
  <li>Load/save properties using methods - I dont want to add order of execution to an already complex setup.</li>
  <li>Table per type  - This wont work because it will double all of my DB queries as i do not know the object type on query time, therefore cannot query the type table to obtain that data at query time.</li>
  <li>Completely new objects - cant do this as i need to keep the objects related so that entity can save an object of type Parent back to the DB</li>
  </ol>