我应该将我的应用程序上下文与用于标识的ApplicationDbContext分开吗？
在Visual Studio 2013中，创建ASP.NET项目时，它会生成一个文件IdentityModels.cs ，其中包含一个ApplicationDbContext类，该类inheritance自IdentityDbContext ，最终inheritance自DbContext 。
我应该仅为帐户相关实体保留此上下文，并为应用程序中的所有其他实体创建单独的上下文，还是应该将其混合使用。
任何安全问题或理由不在一个上下文中包含我的整个应用程序的所有实体？
对此没有正确的答案。 没有与2个不同上下文相关的安全问题。 这一切都归结为您的架构 – 您是否需要创建对您域中用户的引用。 在单独的域中，您无法将EF维护从用户表到域的外键。
有几次我开始使用2个不同的dbContexts，但厌倦了额外的维护，没有任何收益和合并的东西。
而且因为您正在询问这一点，很可能您将无法从2个单独的db-contexts获得任何内容，只会在将来添加额外的代码和不必要的维护。 所以我说只有一个开始。 您可以随时在实际需要时分开。
我会创建一个单独的上下文，主要是因为您可能需要在某个时候将您的用户帐户数据库与您的应用程序数据库分开。 通常，组织的安全策略会要求这样做。如果您没有此要求并且仍然保持两个上下文，则始终可以指向相同的连接字符串。 我更喜欢拆分上下文，因为它使实体映射的流畅api受限。 保持分离还可以选择加密您的身份validationdd，也可能不是您的应用数据，这样可以在安全性和性能之间取得很好的平衡。
这是一个很好的问题，也是我自己考虑的问题。
如果您希望应用程序使用域驱动设计或洋葱架构，该怎么办？
成员资格和身份组件是基础结构或应用程序层组件
应用程序实体通常被视为域层组件。
如果使用单个上下文，则在将上下文实体分离为单独的层而不会损害架构的完整性时会遇到很多困难。
让我知道您在评论中的看法？