我正在学习ASP。. NET MVC和我有一些问题，我读过的教程到现在还没有以一种涵盖我的方式探索。我试着搜索，但我没有看到任何问题问这个。不过，如果我错过了一个现有的，请原谅。
如果我有一个ASP。. NET MVC应用程序，有许多模型(其中一些相关的和一些不相关的彼此)，有多少DbContext子类我应该创建，如果我想使用一个连接字符串和一个数据库全局为我的应用程序?
- 每个模型都有一个上下文?
- 为每组相关模型提供一个上下文?
- 所有模型的一个上下文?
如果答案是前两个之一，那么我应该记住什么，以确保只有一个数据库是为整个应用程序创建的?我问是因为，在Visual Studio本地调试时，在我看来，它创建了尽可能多的数据库，因为有上下文。这就是为什么我发现自己使用第三种选择，但我想知道这是一种正确的做法，还是我犯了某种错误，以后会回过头来咬我。
@jrummell只是部分正确。实体框架将为每个DbContext类型创建一个数据库，如果您将其留给自己的设备。使用@NeilThompson从Julie Lerhman那里提到的"有界上下文"的概念，你所做的就是告诉每个上下文实际上使用相同的数据库。Julie的方法使用了一种通用模式，因此实现该方法的每个DbContext最终都在同一个数据库上，但是您可以为每个DbContext手动执行，如下所示:
public class MyContext : DbContext
{
public MyContext()
: base("name=DatabaseConnectionStringNameHere")
{
Database.SetInitializer(null);
}
}
换句话说，Julie的方法只是建立了一个基类，您的每个上下文都可以从它继承，并自动处理这一部分。
这做了两件事:1)它告诉你的上下文使用一个特定的数据库(即，与其他所有上下文相同)，2)它告诉你的上下文禁用数据库初始化。最后一部分很重要，因为这些上下文现在基本上被视为数据库优先。换句话说，您现在没有上下文可以实际导致创建数据库，或者发出需要进行迁移的信号。因此，您实际上需要另一个"主"上下文，该上下文将包含应用程序中的每个实体。但是，除了创建迁移和更新数据库之外，您不必使用此上下文。对于您的代码，您可以使用更专门的上下文。
对于专门化上下文，要记住的另一件事是，即使它们共享实体，每个上下文的每个实例也表示一个唯一的状态。例如，一个上下文中的Cat实体与另一个上下文中的Cat实体是而不是，即使它们共享相同的主键。如果您从第一个上下文中检索Cat，更新它，然后尝试通过第二个上下文中保存它，那么您将得到一个错误。这个例子有点做作，因为您不太可能在两个不同的上下文中显式地使用相同的实体，但是当您处理外键关系时，遇到这个问题要常见得多。即使您没有显式地为相关实体声明DbSet，如果上下文中的实体依赖于它，EF将隐式地为它创建DbSet。所有这一切都是说，如果你使用专门的上下文，你需要确保它们是真正专门的，并且在任何级别的相关项上都没有交叉。
我使用了Julie Lerman所说的Bounded Context
SystemUsers代码可能与Products无关-所以我可能有一个System DbContext和一个Shop DbContext(例如)。
在小应用程序中使用单个上下文更容易，但对于较大的应用程序，将上下文分开会更有帮助。
通常，每个数据库应该有一个DbContext。但是如果你有独立的，不相关的模型组，那么有单独的DbContext实现是有意义的。
在我看来，它正在创建尽可能多的数据库上下文。
这是正确的，实体框架将创建一个数据库每个DbContext类型