Question

VS2013，EF6代码优先，MVC，（VB）

我想更好地理解使用单个上下文或将DbSets拆分为多个上下文的优缺点。我一直在阅读多个DbContexts上的一些旧SO帖子，并没有找到我想要的东西;关于何时何地使用或不使用多个DbContexts的全面声明。

如果单个用户在自己的硬件上运行Windows Forms等程序，则似乎没有理由拥有多个上下文以便于使用代码。

对于运行多个企业的主要业务程序的Web应用程序，似乎多个DbContexts对于安全性和管理至关重要。

但是如果我正确地考虑这个问题，我想得到确认。我能想到的只有以下几点，但后来我对这个环境很陌生：

单一背景的优点：

单一背景的缺点：

这就是我的全部。我完全不了解双方，并且考虑到我们可以使用的不同环境，似乎一个或多个环境的答案会有所不同。

我目前正在开发一个拥有会员资格的网站，还有一个可下载的应用程序，它将是在用户硬件上运行的个人应用程序。在这种情况下，我认为两者的单一上下文都是有道理的，但在我深入研究之前，我会要求对此进行一些讨论。我认为对环境有所了解的其他人将会继续遇到同样的问题。

我还注意到微软认为在EF6及更高版本中为EF添加多个上下文功能是合适的，所以显然必须有一些编程环境能够产生令人信服的理由来拥有多个上下文。

感谢您的投入。

最诚挚的问候，艾伦

Answer 1

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

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

然而，另一方面，使用多个上下文会带来真正的不利影响。首先，您无法无缝地处理多个对象，除非它们都位于相同的上下文中。此外，由于实体框架的对象图跟踪，多个上下文往往会混淆绿色开发人员。例如，我们假设您有两个实体Foo和Bar，两者都在不同的上下文中。如果您在Bar上与Foo建立了关系：

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

嗯，猜猜怎么着？ Foo 和 Bar现在都由Foo的上下文跟踪。如果您尝试在两种情况下都运行迁移，那么您会收到错误，因为Bar是在两个上下文中管理的，两个上下文。

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

Answer 2

我在评论中看到你提到了学习领域驱动设计。 DDD中的一个概念是Bounded Contexts的概念（请务必查看bubble contexts上的链接资源，以了解如何处理共享实体的两个上下文。）

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

将您的域划分为有界上下文将允许您更轻松地管理大型/复杂域。如果您不需要它，它还可以避免不必要地加载域的部分（在SOA中，您可以自主地将每个有界上下文部署为Udi Dahan称之为Autonomous Business Component的服务）。

在你不得不这样做之前，我不会主张分裂。例如，同时处理域的不同部分的多个团队可能提供进行拆分的好机会，但在某些时候这样做肯定是有意义的。