到目前为止,我的印象是DbContext是用来表示数据库的,因此,如果您的应用程序使用一个数据库,那么您只需要一个DbContext。

然而,一些同事希望将功能区域分解为单独的DbContext类。

我相信这是出于一个好的原因——希望保持代码更干净——但它似乎不稳定。我的直觉告诉我这是个坏主意,但不幸的是,我的直觉并不是设计决策的充分条件。

所以我在寻找:

A)为什么这可能是一个坏主意的具体例子;

B)保证这一切都会顺利解决。


当前回答

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

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

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

其他回答

首先,在代码中,可以有多个DBContext和一个数据库。您只需在构造函数中指定连接字符串。

public class MovieDBContext : DbContext
{
    public MovieDBContext()
        : base("DefaultConnection")
    {

    }
    public DbSet<Movie> Movies { get; set; }
}

嗯,花了相当多的时间在每个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对象本身上。

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

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

总结

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

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

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

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

灵感来自@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。莱托