我想更好地理解使用单个上下文或将DbSets拆分为多个上下文的优缺点.我一直在阅读多个DbContexts上的一些旧SO帖子,并没有找到我想要的东西;关于何时何地使用或不使用多个DbContexts的综合声明.
对于单个用户在自己的硬件上运行Windows Forms等程序的情况,似乎没有理由为了便于使用代码而有多个上下文.
对于运行多个企业的主要业务程序的Web应用程序,似乎多个DbContexts对于安全性和管理至关重要.
但是如果我正确地考虑这个问题,我想得到确认.我能想到的只有以下几点,但后来我对这个环境很陌生：
单一背景的优点：
>编码只有一个上下文要处理
>(跨上下文的关系是否存在问题？)
>迁移更容易,因为只有一个迁移文件夹和进程
>更容易获得在SSMS或EDMX中构建的综合图表
>(Link here用于在首次使用代码时获取EDMX图表)
单一背景的缺点：
>对于企业应用程序上的多个Web客户端,安全性可能是一个问题
>(对于拥有简单会员资格的简单网站,这是一个问题吗？)
>一些SO帖子似乎表明响应时间是一个问题
>(这里的机制是什么？)
这就是我的全部.我完全不了解双方,并且鉴于我们可以使用的环境不同,看起来一个或多个环境的答案会有所不同.
我目前正在开发一个拥有会员资格的网站,还有一个可下载的应用程序,它将是一个在用户硬件上运行的个人应用程序.在这种情况下,我认为两者的单一上下文都是有道理的,但在我深入研究之前,我会要求对此进行一些讨论.我认为对环境有所了解的其他人将继续遇到同样的问题.
我还注意到微软认为适合在EF6及更高版本中为EF添加多个上下文功能,所以显然必须有一些编程环境能够产生令人信服的理由来拥有多个上下文.
感谢您的投入.
最好的祝福,
艾伦
解决方法
拆分上下文没有什么好处. Erik建议大型上下文存在性能问题,但我已经使用了包含50个对象集的单个上下文,并且完全没有注意到性能问题.
然而,另一方面,使用多个上下文确实有害.首先,您无法无缝地处理多个对象,除非它们都位于相同的上下文中.此外,由于Entity Framework的对象图跟踪,多个上下文往往会混淆绿色开发人员.例如,假设您有两个实体,Foo和Bar,两者都在不同的上下文中.如果你创建了与Bar on Foo的关系：
public class Foo
{
public virtual Bar Bar { get; set; }
}
好吧,猜猜怎么着？ Foo和Bar现在都被Foo的上下文跟踪.如果您然后尝试在两个上下文中运行迁移,那么您将收到错误,因为Bar在两个上下文中管理,计算两个上下文.
像这样的错误很容易制造,你会疯狂地试图让一切完全被排除在外.另外,我的论点一直是,如果你的项目中有实体可以完全排除其他实体,那么这就是一个完全独立的项目的论证,而不仅仅是一个不同的上下文.
