我是否应该单独用于身份从ApplicationDbContext我的应用程序上下文？ [英] Should I separate my application context from ApplicationDbContext used for identity?

问题描述

在视觉工作室2013，创建ASP.NET项目时，它会产生一个文件的 IdentityModels.cs 的包含类 ApplicationDbContext ，从继承 IdentityDbContext＆LT; ApplicationUser方式＆gt; ，最终从的DbContext 继承

In Visual-Studio 2013, when creating an ASP.NET project, it generates a file IdentityModels.cs that contains a class ApplicationDbContext, that inherits from IdentityDbContext<ApplicationUser>, which eventually inherits from DbContext.

我应该保持这样的背景下仅帐户有关的实体，并创造了在应用程序中的所有其他实体的独立环境或者我应该混吧。

Should I keep this context only for account-related entities, and created a separate context for all the other entities in the application or should I mix it.

任何安全问题或理由不包括在一个上下文我整个应用程序的所有实体？

Any security issue or reason not to include all the entities of my entire application in one context?

推荐答案

有对此没有正确的答案。有与2个不同的上下文没有安全问题。这一切都下降到您的架构 - 你需要在你的域或不创建用户参考。在不同的域，你不能有EF保持从用户表的外键域。

There is no right answer for this. There is no security issue related to 2 different contexts. It all goes down to your architecture - do you need to create references to users in your domain or not. In separate domains you can't have EF maintaining foreign keys from user tables to domain.

有几次我已经开始用2个不同的dbContexts但厌倦了额外的维护，没有增益和合并的东西融入其中。

A few times I have started with 2 different dbContexts but got tired of extra maintenance and no gain and merged stuff into one.

和因为你问到这个问题，有机会，你不会得到从2个独立的DB-环境无能为力，只能添加额外的code和不必要的维修的未来。所以我说只有一个出发了。当你真正需要它，你可以随时分离。

And because you are asking about this, chances are that you won't gain anything from 2 separate db-contexts, only add extra code and unwanted maintenance in the future. So I say have only one to start off. You can always separate when you actually need it.

这篇关于我是否应该单独用于身份从ApplicationDbContext我的应用程序上下文？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！