Question

我正在学习ASP.NET MVC，而且我有一些问题，我到目前为止所阅读的教程还没有以涵盖我的方式进行探索。我试过搜索，但我没有看到任何问题。如果我错过了现有的，请原谅我。

如果我有一个具有多个模型的ASP.NET MVC应用程序（其中一些相关且一些相互关联），我应该创建多少个DbContext子类，如果我想使用<我的应用程序是全局的一个连接字符串和一个数据库吗？

每个型号的一个背景？
每组相关模型的一个上下文？
所有模特的一个背景？

如果答案是前两个答案之一，那么我是否应该考虑确保只为整个应用程序创建一个数据库？我问，因为在Visual Studio本地调试时，它看起来像是在创建与上下文一样多的数据库。这就是为什么我发现自己使用了第三种选择，但我想知道这是不正确的做法，还是我犯了某种错误，以后再回来咬我。

Answer 1

我使用Julie Lerman所称的Bounded Context

SystemUsers代码可能与Products无关 - 所以我可能有一个系统DbContext和一个Shop DbContext（例如）。

在小应用程序中使用单个上下文可以更轻松地生活，但对于更大的应用程序，它有助于打破上下文。

Answer 2

@jrummell只是部分正确。实体框架将为每个DbContext类型创建一个数据库，如果将其留给自己的设备。使用@NeilThompson从Julie Lerhman提到的“有界上下文”的概念，你所做的只是告诉每个上下文实际使用相同的数据库。 Julie的方法使用通用模式，因此实现它的每个DbContext最终都在同一个数据库上，但你可以手动为每个实现它，如下所示：

public class MyContext : DbContext
{
    public MyContext()
        : base("name=DatabaseConnectionStringNameHere")
    {
        Database.SetInitializer(null);
    }
}

换句话说，Julie的方法只是设置一个基类，你的每个上下文都可以从中继承自动处理这个部分。

这有两件事：1）它告诉你的上下文使用特定的数据库（即，与每个其他上下文相同）和2）它告诉你的上下文禁用数据库初始化。最后一部分很重要，因为这些上下文现在基本上被视为数据库优先。换句话说，您现在没有可以实际创建数据库的上下文，或者表示需要进行迁移的信号。因此，您实际上需要另一个“主”上下文，其中包含应用程序中的每个实体。但是，除了创建迁移和更新数据库之外，您不必将此上下文用于其他任何操作。对于您的代码，您可以使用更专业的上下文。

使用专门的上下文时要记住的另一件事是每个上下文的每个实例化都代表一个唯一状态，即使它们共享实体也是如此。例如，来自一个上下文的Cat实体不与来自第二个上下文的Cat实体相同，即使它们共享相同的主键。如果从第一个上下文中检索Cat，更新它，然后尝试通过第二个上下文保存，则会出现错误。这个例子有点人为，因为你不太可能在两个不同的上下文中明确地拥有相同的实体，但是当你进入外键关系时，遇到这个问题就更常见了。即使您没有为相关实体显式声明DbSet，上下文中的实体也依赖于它，EF将隐式为其创建DbSet。所有这一切都是说，如果你使用专门的上下文，你需要确保它们是真正专业的，并且在相关项的任何级别都有零交叉。

Answer 3

通常，每个数据库应该有一个DbContext。但是如果你有不同的，不相关的模型组，那么单独的DbContext实现是有意义的。

它让我觉得它正在创建尽可能多的数据库上下文。

这是正确的，Entity Framework将为每个DbContext类型创建一个数据库。

与模型相比，我应该拥有多少个DbContext子类？

3 个答案: