My impression to date has been that a DbContext is meant to represent your database, and thus, if your application uses one database, you’d want only one DbContext.
However, some colleagues want to break functional areas out into separate DbContext classes.
I believe this comes from a good place — a desire to keep the code cleaner — but it seems volatile. My gut’s telling me it’s a bad idea, but unfortunately, my gut feeling is not a sufficient condition for a design decision.
So I’m looking for:
A) concrete examples of why this might be a bad idea;
B) assurances that this will all work out just fine.