1

DbContext have properties reflecting the different sets of entities in the database.

I'm using a plugin architecture using MEF and have read similar SO question answering part of my question (MEF Plugins and EF CodeFirst - How?)

But in my core app, I have multiple DbContext (derivatives) that group handfuls of entities together. e.g. SecurityDbContext ConfigurationDbContext.

These contexts only have a few DbSet properties in them.

The article i referenced provides a method by which you have one central DbContext and configure the models in the plugin libraries. This would mean there is one DbContext for the whole application and plugins.

I know EF6 support multiple DbContexts per DB - so does that mean I can just create as many DbContexts as needed - including in the plugins?

I'm assuming that a DbContext can only join (in queries) to entities defined in it irrespective of whether the DbContext is for the same DB.

Any advice appreciated

Community
  • 1
  • 1
sambomartin
  • 6,663
  • 7
  • 40
  • 64
  • 2
    when you use more than one database. – Perfect28 Jun 27 '14 at 14:35
  • It's unclear from your question whether you want to know when to use more than one dbcontext or if you want to know whether you can create as many as you want. Please clarify what you are really after. – Bruno Jun 27 '14 at 14:41
  • @Bruno sorry it's not clear. Essentially I want to know whether it's best practice to use multiple contexts per db. At present (maybe incorrectly) I have DbContext for each "group" of entities. Just because EF6 supports this, I don't suppose makes it the correct way of doing it. The next part of the question I was really asking - for a plugin architecture using MEF, should I create new DbContexts in each plugin, or use a single central DbContext and modify it from each plugin? thanks – sambomartin Jun 27 '14 at 15:03
  • I think [this](http://stackoverflow.com/questions/11197754/entity-framework-one-database-multiple-dbcontexts-is-this-a-bad-idea) SO question can provide you with more detail as to the pros and cons of using multiple dbcontexts per database. From what I gather it's really a tradeoff between complexity and readability of your code. Same goes for deciding whether to use multiple dbcontexts for your plugins. Hope it at least points you in the right direction. – Bruno Jun 27 '14 at 16:33
  • Thanks for your comments. I don't think there is a right answer, but link certainly helped. – sambomartin Jun 30 '14 at 12:12

1 Answers1

0

I thought I'd share my conclusion after reading all the links other users have provided.

It was clear that the DbContext classes I had created didn't include enough entities as I found myself using helper functions I'd written to detach entity objects from other contexts so that they could be attached to other contexts.

The next problem I ran up against was how to deal with DbContexts within a plugin. The plugin may well need to use a "core" entity but also define its own.

Deciding to use a single DbContext for the whole system, using MEF and the solution to this question (MEF Plugins and EF CodeFirst - How?) I was easily able to manipulate the single DbContext to handle additional entities defined in the plugin.

All is working well at present, although I'd read about poor performance of large DbContexts - moving forward, depending on the number of entities and performance of the single DbContext I may well refactor to break up into a series of smaller DbContexts and have a single DbContext with everything in it for managing the database sync.

hope this helps someone with same question

Community
  • 1
  • 1
sambomartin
  • 6,663
  • 7
  • 40
  • 64