【发布时间】:2013-04-27 03:38:25
【问题描述】:
使用实体我目前有 dbcontext,其中包含每个表。
我想知道这是不是每个人都这样做,或者您是否有每个模块的上下文。对我来说,dbcontext 是将模型映射到数据库的连接,由于只有一个数据库,我只需要一个。
在我走得太远之前,我想看看这是否合适。
那么每个数据库 1 db 上下文还是很多?
【问题讨论】:
-
我也有同样的想法
使用实体我目前有 dbcontext,其中包含每个表。
我想知道这是不是每个人都这样做,或者您是否有每个模块的上下文。对我来说,dbcontext 是将模型映射到数据库的连接,由于只有一个数据库,我只需要一个。
在我走得太远之前,我想看看这是否合适。
那么每个数据库 1 db 上下文还是很多?
【问题讨论】:
我最近经历了同样的过程,发现了一些关于这个主题的好资源。以下是非常有帮助的一对:
我正在构建一个桌面应用程序,最终我使用了多个上下文,以便我可以将生命周期与模块而不是应用程序相关联。这对我来说效果很好,我喜欢我的DbContext 不会被DbSets 淹没,并且仅限于与当前模块相关的那些。
在 ASP.NET MVC 应用程序中,情况有所不同,因为 DbContext 只会与请求一样长,在这种情况下,我通常使用单个 DbContext 来简化事情,除非数据库非常大.对于大型数据库,我可能会将其拆分为多个 DbContexts,以限制开销和混乱,并保持分区。
【讨论】:
目前尚未将 EF 分解为 diff dbContexts。 Here a great talk about it
我们为这个案例做了什么,我们从我们的 MVC 网站制作了一个项目差异,仅用于数据库生成,然后为每个需求提供单独的 dbContexts。
这样我们的 dbContexts 永远不会很大并且易于维护
【讨论】: