Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.