问题描述
我正在学习ASP.NET MVC，并且有一些问题，直到现在为止我所阅读的教程都没有以涵盖我的方式进行探讨.我尝试搜索，但是没有看到任何问题.不过，如果我错过了现有的，请原谅我.
I'm learning ASP.NET MVC and I'm having some questions that the tutorials I've read until now haven't explored in a way that covers me. I've tried searching, but I didn't see any questions asking this. Still, please forgive me if I have missed an existing ones.
如果我有一个具有多个模型的ASP.NET MVC应用程序(其中一些相互关联，而另一些彼此不相关)，则如果需要，我应该创建多少个 DbContext 子类.在我的应用程序中全局使用一个连接字符串和一个数据库?
If I have a single ASP.NET MVC application that has a number of models (some of which related and some unrelated with each other), how many DbContext subclasses should I create, if I want to use one connection string and one database globally for my application?
- 每个模型都有一个上下文吗?
- 每组相关模型都有一个上下文吗?
- 所有模型的一个上下文?
如果答案是前两个答案之一，那么我有什么想法可以确保为整个应用程序只创建一个一个数据库?我问是因为，在Visual Studio中进行本地调试时，在我看来，它正在创建与上下文一样多的数据库.这就是为什么我使用第三个选项的原因，但是我想知道这是否是正确的做法，或者我是否犯了某种错误，这种错误会再次出现并在以后咬住我.
If the answer is one of the first two, then is there anything I should have in mind to make sure that only one database is created for the whole application? I ask because, when debugging locally in Visual Studio, it looks to me like it's creating as many databases as there are contexts. That's why I find myself using the third option, but I'd like to know if it's a correct practice or if I'm making some kind of mistake that will come back and bite me later.
推荐答案
@jrummell仅部分正确.实体框架将为每种DbContext类型创建一个数据库， if 则将其留给其自己的设备.使用@NeilThompson从Julie Lerhman提到的有界上下文"的概念，实际上，您要做的就是告诉每个上下文实际使用相同的数据库.朱莉的方法使用通用模式，因此实现它的每个DbContext最终都存储在同一个数据库中，但是您可以为每个数据库手动执行它，如下所示:
@jrummell is only partially correct. Entity Framework will create one database per DbContext type, if you leave it to its own devices. Using the concept of "bounded contexts" that @NeilThompson mentioned from Julie Lerhman, all you're doing is essentially telling each context to actually use the same database. Julie's method uses a generic pattern so that each DbContext that implements it ends up on the same database, but you could do it manually for each one, which would look like:
public class MyContext : DbContext
{
public MyContext()
: base("name=DatabaseConnectionStringNameHere")
{
Database.SetInitializer(null);
}
}
换句话说，朱莉的方法只是建立了一个基类，您的每个上下文都可以从该基类中继承来自动处理这一部分.
In other words, Julie's method just sets up a base class that each of your contexts can inherit from that handles this piece automatically.
这有两件事:1)告诉您的上下文使用特定的数据库(即与其他所有上下文相同)，以及2)告诉您的上下文禁用数据库初始化.最后一部分很重要，因为这些上下文现在基本上已被视为数据库优先.换句话说，您现在没有可以实际导致创建数据库或发出需要进行迁移的信号的上下文.结果，您实际上需要另一个主"上下文，该上下文将在您的应用程序中包含每个单独的实体.但是，除了创建迁移和更新数据库外，您无需将此上下文用于其他任何事情.对于您的代码，您可以使用更专业的上下文.
This does two things: 1) it tells your context to use a specific database (i.e., the same as every other context) and 2) it tells your context to disable database initialization. This last part is important because these contexts are now essentially treated as database-first. In other words, you now have no context that can actually cause a database to be created, or to signal that a migration needs to occur. As a result, you actually need another "master" context that will have every single entity in your application in it. You don't have to use this context for anything other than creating migrations and updating your database, though. For your code, you can use your more specialized contexts.
特殊上下文要记住的另一件事是，即使每个上下文共享实体，每个上下文的每个实例都表示一个 unique 状态.例如，来自一个上下文的 Cat 实体与来自第二个上下文的 Cat 实体不是相同，即使它们共享相同的内容首要的关键.如果从第一个上下文中检索 Cat ，并对其进行了更新，然后尝试通过第二个上下文进行保存，则会出现错误.该示例有些人为的，因为您不可能在两个不同的上下文中显式地拥有相同的实体，但是当您进入外键关系时，碰到这个问题就更加普遍了.即使您没有为相关实体显式声明 DbSet ，它还是上下文中依赖它的实体，EF也会为其隐式创建 DbSet .这就是说，如果您使用特殊的上下文，则需要确保它们是真正的特殊的，并且在相关项目的任何级别上都有零交叉.
The other thing to keep in mind with specialized contexts is that each instantiation of each context represents a unique state even if they share entities. For example, a Cat entity from one context is not the same thing as a Cat entity from a second context, even if they share the same primary key. You will get an error if you retrieved the Cat from the first context, updated it, and then tried save it via the second context. That example is a bit contrived since you're not likely to have the same entity explicitly in two different contexts, but when you get into foreign key relationships and such it's far more common to run into this problem. Even if you don't explicitly declare a DbSet for a related entity, it an entity in the context depends on it, EF will implicitly create a DbSet for it. All this is to say that if you use specialized contexts, you need to ensure that they are truly specialized and that there is zero crossover at any level of related items.
这篇关于关于我的模型，我应该拥有几个DbContext子类?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！