Why multiple DbContext classes?

Question

When I program using LINQ with a .dbml file, there is only one context. But, when I do an MVC site, it seems like I have separate contexts for each entity (which is the way the MVC tutorial showed me how to do it; with "movies" context).

I have:

public class AccountsContext : DbContext { public AccountsContext() : base("DefaultConnection") { } public DbSet<Account> Accounts { get; set; } }

And, I have:

public class ClientsContext : DbContext { public ClientsContext() : base("DefaultConnection") { } public DbSet<Client> Clients { get; set; } }

When I call these, I have to create separate contexts, like:

private AccountsContext db = new AccountsContext(); private ClientsContext clientsContext = new ClientsContext();

... Which is both annoying, and it seems redundant since I know that when I use LINQ, I only have to instantiate a single database object.

Is there a way to use only one contextб and is this recommended?

Bob Horn · Accepted Answer · 2013-04-26 00:59:39Z

There shouldn't be anything stopping you from using one context. The database, and the tooling used to access it, should be completely independent of anything outside of it (business logic, service layer, UI, etc...).

The number of contexts, or how you use them, shouldn't change based on your client technology.

What about MVC leads you to believe that you would need more than one context? And what's stopping you from doing so?

If you think you need to use a context for each entity, because the sample was that way, you don't. Just use one context.

If it helps, this is what a simple context looks like with more than one entity:

public partial class abook_dbEntities : DbContext { public abook_dbEntities() : base("name=abook_dbEntities") { } public DbSet<Entity> Entities { get; set; } public DbSet<Contact> Contacts { get; set; } }

If it helps, a typical business flow looks like this:

UI -> Controller -> Business logic -> Data access -> Database

Your data contexts would go in your data layer. Your logic would go in your business logic layer.

The Movies MVC example specifically and deliberately uses more than one context. asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/…. Why, I don't know. Maybe just to illustrate that it is possible to do so. It might be a desirable thing to do for very large applications; you could create a Context for each department of a corporation, or perhaps each physical database.
Do you know if there was a good reason for that? So maybe the OP is thinking that it has to be done that way, because of that example?
@BobHorn Is there a way to do what you did in separate files? For instance, I would want all logic pertaining to "Accounts" in the accounts.cs file and all logic pertaining to "clients" in the clients.cs file - instead of declaring both accounts and clients in the same file (which could be confusing down the road).
@user1477388 The context class is a partial class, so you could create multiple partial classes. However, logic shouldn't go in these files, they should go in your business logic classes.
@user1477388 Typically a BLL is the one place where business logic is stored. That's so it's not spread across your entire system, and so a line of trust can be drawn around it (security around it). If you have a simple app, and just have models, views, and controllers, then put your logic in the model. It definitely doesn't belong in your data classes.

Collectives™ on Stack Overflow

Why multiple DbContext classes?

1 Answer 1

11 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

11 Comments

Linked

Related