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

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

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

所以我在寻找:

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

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


当前回答

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

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

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