迄今为止，我的印象是 aDbContext用于表示您的数据库，因此，如果您的应用程序使用一个数据库，那么您只需要一个DbContext.
DbContext
但是，一些同事希望将功能区域分解为单独的DbContext类。
我相信这来自一个好地方——保持代码更清洁的愿望——但它似乎不稳定。我的直觉告诉我这是一个坏主意，但不幸的是，我的直觉并不是设计决策的充分条件。
所以我正在寻找：
A）为什么这可能是一个坏主意的具体例子；
B) 保证这一切都会顺利进行。
单个数据库可以有多个上下文。例如，如果您的数据库包含多个数据库模式并且您希望将它们中的每一个作为单独的自包含区域来处理，那么它可能很有用。
问题是当您想首先使用代码来创建数据库时 - 只有应用程序中的单个上下文可以做到这一点。这样做的技巧通常是一个包含所有实体的附加上下文，该上下文仅用于创建数据库。仅包含实体子集的真实应用程序上下文必须将数据库初始化程序设置为 null。
在使用多种上下文类型时，您还会看到其他问题 - 例如共享实体类型及其从一个上下文传递到另一个上下文等。通常，它可以使您的设计更加简洁并分离不同的功能区域，但它有额外复杂性的成本。
