我应该将我的应用程序上下文与用于身份的 ApplicationDbContext 分开吗？答案

【问题标题】：Should I separate my application context from ApplicationDbContext used for identity?我应该将我的应用程序上下文与用于身份的 ApplicationDbContext 分开吗？
【发布时间】：2015-02-01 00:33:41
【问题描述】：

在 Visual-Studio 2013 中，在创建 ASP.NET 项目时，它会生成一个文件 IdentityModels.cs，其中包含一个类 ApplicationDbContext，该类继承自 IdentityDbContext<ApplicationUser>，该类最终继承自DbContext.

我应该只为与帐户相关的实体保留此上下文，并为应用程序中的所有其他实体创建单独的上下文还是应该混合使用它。

是否存在任何安全问题或不将整个应用程序的所有实体包含在一个上下文中的原因？

【问题讨论】：

标签： c# asp.net entity-framework dbcontext asp.net-identity-2

【解决方案1】：

对此没有正确答案。不存在与 2 个不同上下文相关的安全问题。这一切都取决于您的架构 - 您是否需要创建对您域中用户的引用。在单独的域中，您不能让 EF 维护从用户表到域的外键。

有几次我从 2 个不同的 dbContexts 开始，但厌倦了额外的维护，没有收获，于是将东西合并为一个。

而且因为您正在询问这个问题，您很可能不会从 2 个单独的 db-contexts 中获得任何东西，只会在将来添加额外的代码和不需要的维护。所以我说只有一个开始。当你真正需要它时，你可以随时分开。

【讨论】：

是的，我必须将相关应用数据提供给用户。

【解决方案2】：

我会创建一个单独的上下文，主要是因为您可能需要在某些时候将您的用户帐户数据库与应用程序数据库分开。通常组织的安全策略会要求这样做。如果您没有此要求并且仍然维护两个上下文，则始终可以指向相同的连接字符串。我更喜欢拆分上下文，因为它限制了实体映射的流畅 api。保持独立还可以让您选择加密您的身份验证 dd 而可能不是您的应用程序数据，这可以让您在安全性和性能之间取得很好的平衡。

【讨论】：

【解决方案3】：

这是一个很好的问题，也是我自己思考的问题。

如果您希望您的应用程序使用域驱动设计或洋葱架构，该怎么办？

Membership 和 Identity 组件是 infrastructure 或 application 层组件。

应用程序实体通常被视为域层组件。

如果您使用单个上下文，则在不影响架构完整性的情况下将上下文的实体分离到单独的层中会遇到很多困难。

让我知道你对 cmets 的看法？

【讨论】：