实体框架：一个数据库，多个DbContext。这是个坏主意吗？

Question

实体框架：一个数据库，多个DbContext。这是个坏主意吗？到目前为止，我的印象是DbContext表示数据库，因此，如果应用程序使用一个数据库，则只需要一个DbContext。但是，一些同事希望将功能区划分为单独的DbContext类。我相信这来自一个好地方-保持代码清洁的愿望-但它似乎不稳定。我的直觉告诉我这是个坏主意，但不幸的是，我的直觉不是一个设计决策的充分条件。因此，我正在寻找A)具体的例子，为什么这可能是一个不好的想法，或B)保证这一切都会很好。

Answer 1

对于单个数据库，可以有多个上下文。例如，如果数据库包含多个数据库模式，并且希望将其中的每个模式作为单独的自包含区域处理，则会非常有用。

问题是当您想首先使用代码来创建数据库时-只有应用程序中的单个上下文才能做到这一点。这方面的诀窍通常是包含所有实体的附加上下文，这些实体仅用于数据库创建。您的实际应用程序上下文只包含实体的子集，必须将数据库初始化程序设置为NULL。

在使用多个上下文类型时，您还会看到其他问题-例如共享实体类型及其从一个上下文传递到另一个上下文，等等。一般来说，它可以使您的设计更加干净，并且将不同的功能区域分离开来，但它在额外的复杂性中也有代价。