Question

Just curious.

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.

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.

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?

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?

Or is it better to keep these operations separate for each grid?

Hmmm..

Answer 1

It depends.

On top of all rules I would say: Keep it simple and don’t repeat yourself.

Some comments:

Say I have a Base entity and I’m deriving about 10 different child
entities from it using the Table Per Type method.

Only as a side note: You are aware of the poor performance (at least for EF < 5) of TPT, right? It is something to keep in mind especially if the tables can be large or you have a deep inheritance hierarchy (entities derived from derived entities…, etc.)

I eventually want to map each of the child entities to a separate view
model

Which is in my opinion a good idea, alone for possible different validation rules you might apply to the ViewModels for each derived entity.

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?

To mimic the inheritance of entities is not a reason in my opinion. But if you have for example view validation rules on base model properties and they apply to all derived entities why not keeping those rules in one place – like a base ViewModel. Otherwise you had to repeat them in every derived ViewModel.

Should each view model have its own set of CRUD operations in this
case?

If the derived entities are “flat” (have only scalar properties and no navigation properties) you only would need something like:

Read: context.BaseEntities.OfType<T>().Where(...)...
Add: context.BaseEntities.Add(T entity);
Delete: context.BaseEntities.Remove(T entity);
Update: context.Entry(object o).State = EntityState.Modified;

All these methods work for base and derived entities. Why would you want to create such methods for each entity separately? You might need separate methods though in more complex situations, for example if derived entity number 7 has a navigation property to another entity and your view for that entity does allow to change relationships to the other entity. So, it depends. I would not start with duplicating methods that all do the same, rather refactor later when I see that I need special handling (unless maybe when you can foresee from the beginning that special handling is expected at some point during the project evolvement).

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?

On repository/service side, yes, if only scalar properties are loaded for each derived entity. If you need navigation properties for derived entity 7 you may need something special (maybe an Include). Projecting the data into the ViewModels might be specific for every entity because you have separate ViewModels per entity.

Should I be using reflections?

WTF? Why that? Better not.

Should I be making use of polymorphic properties of the parent/child
entities?

??? (<- this is supposed to be a “Confused”-Emoticon)