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-26T00:59:39.823

13

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.

edited Apr 26 '13 at 00:59

answered Apr 25 '13 at 23:38

Bob Horn

33,387
34
113
219

5

The Movies MVC example specifically and deliberately uses more than one context. http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/adding-a-model. 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. – Robert Harvey Apr 25 '13 at 23:42
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? – Bob Horn Apr 25 '13 at 23:44
@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 Apr 26 '13 at 00:09
@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. – Bob Horn Apr 26 '13 at 00:34
@RobertHarvey The only hard requirement i know of for needing a second context would be if you need a separate connection string (eg separate DB or user) however as you say its sometimes nice to break stuff down by domain and have a context per domain. We do this often – undefined Apr 26 '13 at 02:05
@BobHorn Sorry for confusing; I have two files in /Models: accounts.cs and clients.cs. I don't think I have a business logic layer. I just have MVC (models, views and controllers). What is the construct for a business logic layer? From this post http://stackoverflow.com/questions/4565681/where-does-the-business-logic-layer-fit-in-to-an-mvc-application it sounds like they're talking about a view model... – user1477388 Apr 26 '13 at 12:21
1

@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. – Bob Horn Apr 26 '13 at 12:33
@BobHorn Thanks, but I am still wondering: How can I put `public DbSet Entities { get; set; }` in it's respective Entity.cs model and `public DbSet Contacts { get; set; }` in it's respective Contacts.cs model, without having using a separate context? Is it possible? – user1477388 Apr 26 '13 at 12:35
Yes, it's possible. When you first create your edmx (designer/context), select all the tables you want and it will be created for you. – Bob Horn Apr 26 '13 at 12:56
@BobHorn Sorry to take up any of your time with this by asking subsequent questions; but I am using code first. I don't select tables via a designer like I do when I use LINQ (.dbml). I just write my model and MVC creates the database for me. – user1477388 Apr 26 '13 at 12:58
So, I've done code first, but it has been a while. Yes, you can still have one context, but I don't remember how off the top of my head. When I did it, I didn't have to do anything special to have just one context. If you do some googling, you'll get it. – Bob Horn Apr 26 '13 at 13:22

Why multiple DbContext classes?

1 Answers1

Linked