I went through this same process recently and found some great resources on the subject. Here are a couple that were very helpful:
I was building a Desktop app, and I ended up using multiple contexts so that I could keep the lifetime tied to the module rather than the application. This has worked out very well for me, and I like that my DbContext
isn't swamped with DbSets
and is limited to the ones that are relevant for the current module.
In an ASP.NET MVC app, it is different since the DbContext
will only live as long as the request, and in those cases, I usually use a single DbContext
to simplify things unless the database is very large. With a large database, I would probably break it apart into multiple DbContexts
just to limit the overhead and the clutter, and keep things compartmentalized.