1

Here's the situation. I have an enterprise application that uses EF Codefirst to map POCOs to an existing database. This has been working fine so far. In fact I would say that it's been working really well.

A situation has been introduced (out of my hands) that involves adding new tables to the database and/or new columns to tables when a customer has purchased an add-on.

There aren't clear domain boundaries. So, I find myself in a difficult position because I need to support an entity at the base product level, but then I need to support the same entity (emphasis on this entity being considered the same) with a few new columns. Additionally, the entity may have new relationships to new tables.

It appears that it is possible to add entities to a schema (see http://romiller.com/2012/03/26/dynamically-building-a-model-with-code-first/ for a general approach) but it doesn't address properties and relationships. Is it possible or even feasible to change a DbContext's schema and models at runtime?

The application is using ASP.NET MVC WebAPI with a repository pattern. So, as a last resort I am considering the possibility that I'll need to stop using EF and replace it with ADO.NET instead, but that (of course) will be a very labor and time intensive process.

Thanks for any help.

Improve this question
6
  • You would only need ADO.NET for those parts of the database that are customer add-ons. Or, simply include the additional schemas for the add-ons in everyone's database and EF context, and control access to them through feature security.
    – Robert Harvey
    Sep 24, 2013 at 21:28
  • The existing EF models would need to be updated with the relationship to the new add-on table.
    – quakkels
    Sep 24, 2013 at 21:32
  • You do that by providing a new software release, if theirs doesn't already have the new feature.
    – Robert Harvey
    Sep 24, 2013 at 21:33
  • There are several different products that this application needs to support. That's the unfortunate part. By simply installing an add-on, the existing entity needs to change... that needs to be supported in the application. That's why I said there aren't clear domain boundaries.
    – quakkels
    Sep 24, 2013 at 21:37
  • 1
    You are making an assumption that you may not need to make. Would you rather write an engine that dynamically adds new features to your database schema and context as they are needed, or simply include those features from the start and allow the addins to access them when they're bought and paid for?
    – Robert Harvey
    Sep 24, 2013 at 21:40

1 Answer 1

Reset to default
1

It seems to me that changing things at runtime is going to land you in several nested worlds of hurt.

The question I would be asking is whether this is the best way to implement these add-ons. I can see two useful alternatives:

  • If the add-ons are standard, then you could use Table Per Heirarchy inheritance to represent the different versions of the table. In the data store you would have a single larger table with all the columns, but depending on the user's requirements you could choose different entities that include or exclude the extra data.
  • If the add-ons are non-standard then you will need different underlying code regardless. In this case different customers will require different implementations entirely and you might use a Dependency Injection container to allow you to switch between options for any given deployment.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.