在EF中使用单个或多个DbContext的优缺点是什么？

在我看来,拥有多个上下文的唯一理由是,如果您有多个数据库在运行.例如,我使用的一个应用程序有3个上下文.两个上下文适用于应用程序不直接负责的现有数据库,而第三个上下文是具有迁移的特定于应用程序的上下文.

拆分上下文没有什么好处.Erik建议大型上下文存在性能问题,但我已经使用了包含50多个对象集的单个上下文,并且完全没有注意到性能问题.

然而,另一方面,使用多个上下文确实有害.首先,您无法无缝地处理多个对象,除非它们都位于相同的上下文中.此外,由于Entity Framework的对象图跟踪,多个上下文往往会混淆绿色开发人员.例如,假设您有两个实体,Foo并且Bar都在不同的上下文中.如果您创建了与Baron 的关系Foo:

public class Foo
{
    public virtual Bar Bar { get; set; }
}

好吧,猜猜怎么着？无论Foo 和 Bar现在被跟踪Foo的上下文.如果您然后尝试在两个上下文中运行迁移,那么您将收到错误,因为它Bar是在两个上下计算的,计数'em,两个上下文.

像这样的错误很容易制造,你会疯狂地试图让一切完全被排除在外.另外,我的论点一直是,如果你的项目中有实体可以完全排除其他实体,那么这就是一个完全独立的项目的论证,而不仅仅是一个不同的上下文.

我在评论中看到您提到学习域驱动设计。DDD中的概念之一是绑定上下文（一定要检查气泡上下文中的链接资源，以了解如何处理共享实体的两个上下文）。

它使绝对意义上使用每个单独的DbContext映射你的限界上下文。在执行此操作时，您需要警惕某些陷阱，但是遵循DDD方法应该可以帮助您避免这些陷阱。主要对象是共享实体。一个上下文应负责控制共享实体的生命周期，另一上下文应仅查询那些实体，而不对它们进行任何更改。

将您的域划分为有限的上下文将使您可以更轻松地管理大型/复杂域。如果您不需要，也可以避免不必要地加载域的某些部分（在SOA中，您可以将每个有界上下文作为服务自动部署为Udi Dahan称为“ 自治业务组件”）。

除非必须，否则我不主张进行拆分。例如，多个团队同时处理域的不同部分可能会提供一个很好的机会进行拆分，但是在某个时候这样做绝对是有意义的。