将单个或多个 DbContext 与 EF 结合使用的优缺点是什么

本文关键字：结合是什么优缺点 EF 单个 DbContext | 更新日期: 2023-09-27 18:33:53

>VS2013， EF6 code first， MVC， (VB(

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

如果单个用户在自己的硬件上运行程序(如 Windows 窗体(，则似乎没有理由使用多个上下文来简化代码。

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

但是，如果我正确考虑了这个问题，我想得到确认。我能想到的只有以下内容，但是我对这种环境很陌生：

单一上下文的优点：

单一上下文的缺点：

这就是我所拥有的一切。我没有足够的知识来完全理解这两个方面，考虑到我们可以工作的不同环境，似乎对一个或多个背景的答案会有所不同。

我目前正在开发一个具有会员资格的网站，以及一个可下载的应用程序，该应用程序将在用户的硬件上运行的个人应用程序。在这种情况下，我认为两者的单一上下文是有意义的，但在我深入探讨之前，我想我会要求对此进行一些讨论。我想其他对环境有些陌生的人也会继续有同样的问题。

我还注意到，Microsoft认为适合在 EF6 及更高版本中向 EF 添加多上下文功能，因此显然必须有一些编程环境产生具有多个上下文的令人信服的理由。

感谢您的输入。

此致敬意Alan

将单个或多个 DbContext 与 EF 结合使用的优缺点是什么

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

拆分上下文没有真正的好处。Erik 建议大型上下文存在性能问题，但我使用过包含 50+ 个对象集的单个上下文，并且根本没有注意到任何性能问题。

但是，另一方面

，使用多个上下文确实存在危害。首先，您将失去无缝处理多个对象的能力，除非它们都驻留在同一个上下文中。此外，由于实体框架的对象图跟踪，多个上下文往往会使绿色开发人员感到困惑。例如，假设您有两个实体，Foo 和 Bar ，它们都位于不同的上下文中。如果您创建了关系以Bar Foo：

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

好吧，你猜怎么着？Foo和Bar现在都由Foo的上下文跟踪。如果随后尝试在两个上下文上运行迁移，则会收到错误，因为Bar在两个上下文中管理，算上它们，两个上下文。

像这样的错误很容易犯，你会把自己逼疯，试图让一切都完全排除在外。另外，我的论点一直是，如果你的项目中有可以完全排除的实体，那么这是一个完全独立的项目的论据，而不仅仅是一个不同的上下文。

我在评论中看到你提到学习领域驱动设计。DDD 中的概念之一是界定上下文(请务必查看气泡上下文上的链接资源，了解如何处理共享实体的两个上下文(。

为每个

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

通过将域分隔到边界上下文中，可以更轻松地管理大型/复杂域。它还避免了在不需要域的某些部分时不必要地加载它们(在 SOA 中，您可以将每个边界上下文自主部署为服务，Udi Dahan 称之为自治业务组件(。

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