Multiple DbContext classes for a single web app. Good or bad?

Question

Is it a good practice to have multiple XXX : DbContext classes for each major section of a web application (considering it's a big one with at least 50 tables in its database)? For example: MembershipContext, BlogContext, StoreContext etc. Or it's more convenient to have a single DatabaseContext for all the db access related stuff.

Answer 1

Using multiple DbContext classes implies complicating cross-transactions (you can find a solution to this problem on the web here an example http://pastebin.com/YEDqyH0n) but may be justified. It all depends on your architecture and the separation that you want to design.

Anyways you should look at the Repository and UnitOfWork patterns to have a layer of abstractation of how to use your DbContexts. Look here: Multiple DbContexts in N-Tier Application and here EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)? if you use ASP.NET MVC.

For 50 tables I think it may be justified to have multiple DbContexts. So I would recommend using multiple DbContexts. But you should wrap them using the Repository and UnitOfWork patterns to be independant from the actual implementation in the other layers (like this you could easily change your mind later and only use a signle DbContext for example).

I hope that helps.