拥有多个数据上下文是一种好习惯吗？

Question

将解决方案分解为多个项目时，有多个数据上下文或共享上下文是否有意义？

示例，对于您拥有的门户网站：

App.Service1
App.Service2
App.Web (references Service1 and Service2)

现在你能拥有它，以便Service1和Service2共享相同的DataContext，或者每个都有自己的吗？

请注意，Service1和Service2都连接到完全相同的数据库，它们只是分开，以便让事情更加孤立。

我正在使用EF6。

Answer 1

最好共享相同的上下文。当您聚合来自不同数据库的数据时，多个上下文是有意义的。

Answer 2

我会主要使用单个上下文，因为如果两个上下文存在于同一个数据库中，它会阻止Entity Framework与迁移或模式更改检测混淆

如果分离是一个问题并且您的设计允许它，我将使上下文实现两个接口，这是Service1和Service2的逻辑拆分，并使用整个代码中的接口。

值得注意的是，你不能在导航属性方面拥有交叉上下文关系，但这听起来不像是你的问题

Answer 3

一般情况下，我建议您使用一个上下文以简化，但如果您使用多个上下文，则数据模型（上下文）非常大，可能会有更好的性能。但只有你的实体没有关系才有意义。并且处理许多情况可能很困难。

Answer 4

我个人认为没有使用同一个数据库的两个数据上下文。我认为你的想法是孤立的，但我认为EF足够强大，不会这样做。正如@Darin所说，我对不同的数据库使用了两种情境。