灵感来自@JulieLerman的DDD MSDN Mag文章2013

public class ShippingContext : BaseContext<ShippingContext>
{
  public DbSet<Shipment> Shipments { get; set; }
  public DbSet<Shipper> Shippers { get; set; }
  public DbSet<OrderShippingDetail> Order { get; set; } //Orders table
  public DbSet<ItemToBeShipped> ItemsToBeShipped { get; set; }
  protected override void OnModelCreating(DbModelBuilder modelBuilder)
  {
    modelBuilder.Ignore<LineItem>();
    modelBuilder.Ignore<Order>();
    modelBuilder.Configurations.Add(new ShippingAddressMap());
  }
}

public class BaseContext<TContext>
  DbContext where TContext : DbContext
{
  static BaseContext()
  {
    Database.SetInitializer<TContext>(null);
  }
  protected BaseContext() : base("DPSalesDatabase")
  {}
}   

如果你正在进行新的开发，你想让Code First基于你的类创建或迁移你的数据库，你将需要使用DbContext创建一个“超级模型”，其中包括构建一个表示数据库的完整模型所需的所有类和关系。但是，这个上下文不能继承自BaseContext。莱托

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

在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";
    }
}

总结

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

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

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

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

嗯，花了相当多的时间在每个DB模式的独立DB上下文的问题上，希望它能帮助其他人…

我最近开始从事一个项目，其中一个数据库有3个模式(DB优先方法)，其中一个用于用户管理。每个单独的模式都有一个DB上下文。当然，用户也与其他模式相关，例如。schema KB有一个表Topic，它有“由谁创建的”，“最后修改的是谁”等。FK到标识模式，表appuser。

这些对象是在c#中单独加载的，首先，topic是从一个上下文加载的，然后用户是通过用户id从另一个db上下文加载的-不太好，必须修复这个! (类似于使用EF 6在同一个数据库中使用多个dbcontext)

首先，我尝试将身份模式中缺失的FK指令添加到KB模式中，添加到KB DB上下文中的EF modelBuilder中。就像只有1个上下文一样，但我把它分离成2个。

modelBuilder.Entity<Topic>(entity =>
{
  entity.HasOne(d => d.Creator)
    .WithMany(p => p.TopicCreator)
    .HasForeignKey(d => d.CreatorId)
    .HasConstraintName("fk_topic_app_users");

它没有工作，因为kb db context没有任何关于用户对象的信息，postgres返回错误关系“AppUsers”不存在。选择语句没有正确的模式，字段名等信息。

我几乎放弃了，但后来我注意到一个开关“-d”运行dotnet ef dbcontext脚手架。它是-data-annotations的缩写-使用属性配置模型(在可能的情况下)。如果省略，则只使用fluent API。 通过指定这个开关，对象属性不是在db上下文OnModelCreating()中定义的，而是在对象本身上定义的，带有属性。

通过这种方式，EF获得了足够的信息，可以用正确的字段名和模式生成正确的SQL语句。

TL;DR:单独的DB上下文不能很好地处理它们之间的关系(FKs)，每个上下文只有关于自己实体的信息。 当在dotnet ef dbcontext scaffold上指定“-data-annotations”开关时，这些信息不是存储在每个单独的上下文中，而是存储在DB对象本身上。

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

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

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

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

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