title: Good programming principles while using EF/Code First/Repository Pattern/Table Per Type (TPT)?
body: <p>Just curious.</p>
  
  <p>Say I have a Base entity and I'm deriving about 10 different child entities from it using the Table Per Type method. I also have a generic repository which can fetch me data from each of these child entities. I eventually want to map each of the child entities to a separate view model and link each of the view models to its own grid (JqGrid) on my website, with each grid having its own Create, Read, Update, Delete methods. I can do all of that, but I'm not sure what's the proper way to go about it while keeping code to a minimum.</p>
  
  <p>Right now, I have every field defined (from both the parent and child entity) in each of my view models. Is it better to have a "parent" view model and then deriving the child view models from it in order to mimic the inheritance structure of the entities? I wouldn't think so....having inheritance in view models doesn't make much sense to me.</p>
  
  <p>Also, I really don't want to duplicate CRUD operations for each grid. Is that considered good practice? Should each view model have its own set of CRUD operations in this case?</p>
  
  <p>Take 'Read' for instance. I'm basically returning JSON data based on the ID (key) field of the view model for each grid. And since all grids will have this ID column (part of the parent entity), should I only have one function that takes care of this for all grids? Should I be using reflections? Should I be making use of polymorphic properties of the parent/child entities?</p>
  
  <p>Or is it better to keep these operations separate for each grid?</p>
  
  <p>Hmmm..</p>