相关疑难解决方法(0)

我的印象是DbContext意味着代表你的数据库,因此,如果你的应用程序使用一个数据库,你只需要一个DbContext.但是,有些同事希望将功能区域分解为单独的DbContext类.我相信这来自一个好地方 - 希望保持代码清洁 - 但它似乎不稳定.我的直觉告诉我这是一个坏主意,但不幸的是,我的直觉并不是设计决策的充分条件.

所以我正在寻找A)为什么这可能是一个坏主意的具体例子,或B)保证这一切都很好.

我有一个使用EF作为ORM的应用程序.数据库曾经有一个架构,dbo,一切都运行正常.我最近将我的表组织成4种不同的模式.一个模式的某些表依赖于驻留在不同模式上的表.所有似乎都在SQL方面有效.

在应用程序端,通过EF的所有数据库交互都不再起作用.代码编译,模式在解决方案中可见,模型映射指向正确的模式,但是一旦我尝试向表中插入行,它就不起作用.

我看过一些关于使用多个模式的帖子需要使用多个DBContexts,但我宁愿使用一个DBContext.我的所有模式都拥有相同的所有者dbo,我没有看到使用多个DBContexts的原因.

有谁知道是否有办法实现这一目标？