另一点“智慧”。我有一个面向互联网和内部应用程序的数据库。每一个面向都有一个上下文。这有助于我保持纪律严明的隔离。

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

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

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

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

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

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

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

总结

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

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

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

我想分享一个案例，我认为在同一个数据库中有多个dbcontext的可能性是很有意义的。

我有一个解决方案与两个数据库。一个是除用户信息外的域数据。另一个仅用于用户信息。这一划分主要是由欧盟通用数据保护条例推动的。通过拥有两个数据库，我可以自由地移动域数据(例如，从Azure移动到我的开发环境)，只要用户数据保持在一个安全的地方。

现在，对于用户数据库，我已经通过EF实现了两个模式。一个是AspNet身份框架提供的默认身份。另一个是我们自己实现任何与用户相关的东西。与扩展ApsNet模式相比，我更喜欢这种解决方案，因为我可以轻松地处理未来对AspNet身份的更改，同时这种分离使程序员清楚地知道，“我们自己的用户信息”应该放在我们定义的特定用户模式中。

另一点“智慧”。我有一个面向互联网和内部应用程序的数据库。每一个面向都有一个上下文。这有助于我保持纪律严明的隔离。