我四年前写了这个答案，我的观点一直没有改变。但自那以后，微服务领域有了重大发展。我在最后添加了特定的微服务注释……

我会权衡反对这个想法，用实际经验来支持我的投票。

我曾参与一个大型应用程序，该应用程序为单个数据库提供了五个上下文。最后，我们删除了所有的上下文，只有一个例外——返回到单个上下文。

起初，多重上下文的想法似乎是个好主意。我们可以将数据访问划分为域，并提供几个干净的轻量级上下文。听起来像DDD，对吧?这将简化我们的数据访问。另一个理由是为了性能，因为我们只访问我们需要的上下文。

但在实践中，随着应用程序的增长，许多表在各种上下文之间共享关系。例如，对上下文1中的表A的查询也需要连接上下文2中的表B。

这给我们留下了一些糟糕的选择。我们可以在不同的上下文中复制这些表。我们试过了。这产生了几个映射问题，包括一个EF约束，它要求每个实体都有唯一的名称。因此，我们在不同的上下文中得到了名为Person1和Person2的实体。有人可能会说这是我们糟糕的设计，但尽管我们尽了最大的努力，这就是我们的应用程序在现实世界中实际发展的方式。

我们还尝试查询两个上下文以获得所需的数据。例如，我们的业务逻辑将从上下文1查询所需内容的一半，从上下文2查询所需内容的另一半。这有一些主要的问题。我们必须跨不同的上下文执行多个查询，而不是针对单个上下文执行一个查询。这有一个真正的性能损失。

最后，好消息是很容易剥离出多个上下文。上下文是一个轻量级对象。所以我不认为性能在多种情况下都是一个很好的理由。在几乎所有情况下，我认为单个上下文更简单、更简单，而且可能性能更好，您不必实现一堆变通方法来让它工作。

I thought of one situation where multiple contexts could be useful. A separate context could be used to fix a physical issue with the database in which it actually contains more than one domain. Ideally, a context would be one-to-one to a domain, which would be one-to-one to a database. In other words, if a set of tables are in no way related to the other tables in a given database, they should probably be pulled out into a separate database. I realize this isn't always practical. But if a set of tables are so different that you would feel comfortable separating them into a separate database (but you choose not to) then I could see the case for using a separate context, but only because there are actually two separate domains.

对于微服务，单一的上下文仍然是有意义的。然而，对于微服务，每个服务都有自己的上下文，其中只包括与该服务相关的数据库表。换句话说，如果服务x访问表1和表2，服务y访问表3和表4，那么每个服务都有自己的唯一上下文，其中包含特定于该服务的表。

我对你的想法很感兴趣。

单个数据库可以有多个上下文。例如，如果您的数据库包含多个数据库模式，并且您希望将每个模式作为独立的自包含区域来处理，那么它就很有用。

问题是，当您想首先使用代码来创建数据库时，只有应用程序中的单个上下文可以做到这一点。这样做的技巧通常是一个额外的上下文，其中包含仅用于数据库创建的所有实体。仅包含实体子集的实际应用程序上下文必须将数据库初始化式设置为null。

在使用多种上下文类型时，还会遇到其他问题——例如共享实体类型及其从一个上下文传递到另一个上下文等等。一般来说，这是可能的，它可以使你的设计更干净，并分离不同的功能区域，但它的代价是额外的复杂性。

My gut told me the same thing when I came across this design. I am working on a code base where there are three dbContexts to one database. 2 out of the 3 dbcontexts are dependent on information from 1 dbcontext because it serves up the administrative data. This design has placed constraints on how you can query your data. I ran into this problem where you cannot join across dbcontexts. Instead what you are required to do is query the two separate dbcontexts then do a join in memory or iterate through both to get the combination of the two as a result set. The problem with that is instead of querying for a specific result set you are now loading all your records into memory and then doing a join against the two result sets in memory. It can really slow things down. I would ask the question "just because you can, should you?" See this article for the problem I came across related to this design. The specified LINQ expression contains references to queries that are associated with different contexts

提醒:如果你要组合多个上下文，请确保你在各种RealContexts.OnModelCreating()中剪切和粘贴所有功能到你的单个CombinedContext.OnModelCreating()。

我只是浪费时间寻找为什么我的级联删除关系没有被保存，却发现我没有移植modelBuilder.Entity<T>()....WillCascadeOnDelete();代码从我的真实上下文到我的组合上下文。

实现以下简单示例:

    ApplicationDbContext forumDB = new ApplicationDbContext();
    MonitorDbContext monitor = new MonitorDbContext();

只在main上下文中设置属性范围:(用于创建和维护DB) 注意:只使用protected:(这里没有显示实体)

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("QAForum", throwIfV1Schema: false)
    {

    }
    protected DbSet<Diagnostic> Diagnostics { get; set; }
    public DbSet<Forum> Forums { get; set; }
    public DbSet<Post> Posts { get; set; }
    public DbSet<Thread> Threads { get; set; }
    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
    }
}

MonitorContext: 在这里暴露单独的实体

public class MonitorDbContext: DbContext
{
    public MonitorDbContext()
        : base("QAForum")
    {

    }
    public DbSet<Diagnostic> Diagnostics { get; set; }
    // add more here
}

诊断模型:

public class Diagnostic
{
    [Key]
    public Guid DiagnosticID { get; set; }
    public string ApplicationName { get; set; }
    public DateTime DiagnosticTime { get; set; }
    public string Data { get; set; }
}

如果您愿意，可以在主ApplicationDbContext中将所有实体标记为受保护的，然后根据需要为每个模式分离创建额外的上下文。

它们都使用相同的连接字符串，但是它们使用不同的连接，因此不要交叉事务并注意锁定问题。一般来说，你的设计是分离的，所以这种情况不应该发生。

通过设置默认模式来区分上下文

在EF6中，您可以有多个上下文，只需在DbContext派生类的OnModelCreating方法中指定默认数据库模式的名称(其中有Fluent-API配置)。 这将在EF6工作:

public partial class CustomerModel : DbContext
{   
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("Customer");

        // Fluent API configuration
    }   
}

本例将使用“Customer”作为数据库表的前缀(而不是“dbo”)。 更重要的是，它还将作为__MigrationHistory表的前缀，例如Customer.__MigrationHistory。 因此，在一个数据库中可以有多个__MigrationHistory表，每个上下文对应一个。 因此，对一个上下文所做的更改不会影响到另一个上下文。

添加迁移时，在add-migration命令中指定配置类的全限定名称(派生自DbMigrationsConfiguration)作为参数:

add-migration NAME_OF_MIGRATION -ConfigurationTypeName FULLY_QUALIFIED_NAME_OF_CONFIGURATION_CLASS

上下文键上的一个简短的单词

根据这篇MSDN文章“章节-多个模型针对同一个数据库”，EF 6可能会处理这种情况，即使只有一个MigrationHistory表存在，因为在表中有一个ContextKey列来区分迁移。

但是，我更喜欢通过指定如上所述的默认模式来拥有多个MigrationHistory表。

使用单独的迁移文件夹

在这种情况下，您可能还想在项目中使用不同的“Migration”文件夹。你可以使用MigrationsDirectory属性设置你的DbMigrationsConfiguration派生类:

internal sealed class ConfigurationA : DbMigrationsConfiguration<ModelA>
{
    public ConfigurationA()
    {
        AutomaticMigrationsEnabled = false;
        MigrationsDirectory = @"Migrations\ModelA";
    }
}

internal sealed class ConfigurationB : DbMigrationsConfiguration<ModelB>
{
    public ConfigurationB()
    {
        AutomaticMigrationsEnabled = false;
        MigrationsDirectory = @"Migrations\ModelB";
    }
}

总结

总而言之，您可以说所有内容都被清晰地分离了:项目中的上下文、迁移文件夹和数据库中的表。

我会选择这样的解决方案，如果有一组实体是一个更大的主题的一部分，但彼此不相关(通过外键)。

如果实体组之间没有任何关联，我会为它们每个创建一个单独的数据库，并在不同的项目中访问它们，可能每个项目中都有一个上下文。