为什么多个DbContext类？ [英] Why multiple DbContext classes?

问题描述

当我使用LINQ与.dbml文件进行编程时，只有一个上下文。但是，当我做一个MVC网站时，似乎我对每个实体都有单独的上下文（这是MVC教程如何显示我的方式;使用电影上下文）。

我有：

  public class AccountsContext：DbContext 
 {
 public AccountsContext ）
：base（DefaultConnection）
 {
} 
 
 public DbSet< Account>帐户{get;组; } 
} 
  

而且我有：

  public class ClientsContext：DbContext 
 {
 public ClientsContext（）
：base（DefaultConnection）
 {
} 
 
 public DbSet< Client>客户{get;组; } 
} 
  

当我调用这些，我必须创建单独的上下文，如： / p>

  private AccountsContext db = new AccountsContext（）; 
 private ClientsContext clientsContext = new ClientsContext（）; 
  

...哪个都很烦人，看起来很多，因为我知道当我使用LINQ，我只需要实例化一个数据库对象。

有没有办法只使用一个contextб，这是推荐吗？

解决方案

不应该有任何阻止你使用一个上下文的东西。数据库和用于访问它的工具应该完全独立于它之外的任何东西（业务逻辑，服务层，UI等）。

上下文的数量或使用方式不应该根据您的客户端技术进行更改。

MVC如何让您相信您将需要多于一个背景？那么阻止你这样做的是什么？

如果你认为你需要为每个实体使用上下文，因为样例是这样的。只需使用一个上下文。

如果它有帮助，这是一个简单的上下文看起来与多个实体：

$ base
}

public DbSet< Entity>实体{get;组; }
public DbSet< Contact>联系人{get;组; }
}

如果有帮助，典型的业务流程如下所示：

UI - >控制器 - >业务逻辑 - >数据访问 - >数据库

您的数据上下文将进入数据层。您的逻辑将进入您的业务逻辑层。

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?

解决方案

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.

这篇关于为什么多个DbContext类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！