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

architecture coding-style entity-framework repository-pattern


Is having multiples a wise move?XXX : DbContext classes for every significant portion of a large online application with at least 50 tables in its database? As an example, consider MembershipContext, BlogContext, StoreContext, etc. Or having only one is more practical.DatabaseContext for any matters relating to database access.

6/17/2012 4:16:45 PM

Accepted Answer

While it may be justified, using numerous DbContext classes complicates cross-transactions (you may find a solution to this issue online here with an example Everything relies on your architectural style and the kind of distinction you want to create.

In any case, if you want to have a layer of abstraction around how to utilize your DbContexts, you should look at the Repository and UnitOfWork patterns. If you use ASP.NET MVC, look here: DbContexts in N-Tier Applications with Multiple and here: Any problems (performance, data integrity) if using the EF and repository approach and ending up with numerous DbContexts in one controller?.

I believe having several DbContexts may be appropriate for 50 tables. Therefore, I advise utilizing numerous DbContexts. But to be independent from the actual implementation in the other levels, you need wrap them in the Repository and UnitOfWork patterns (like this you could easily change your mind later and only use a signle DbContext for example).

Hope that was helpful.

5/23/2017 11:46:55 AM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow