C# 我是否需要运行时数据库上下文的OnModelCreating中的实体数据模型？

因此，我以以下方式使用EF DbContexts。一个

AppDbContext

是从

DbContext

派生的抽象类，它包含我的数据库集，并用作注入服务的类型。它的“实现”类似于

AppDbContextMySql

，这是不言自明的-它派生自

AppDbContext

，并处理到实际数据库的连接。可以有几个这样的抽象/实现对来分隔数据表，但是通常，它们都指向同一个实际的DB实例

然后我需要全部迁移，因此我添加了一个

MigrationDbContext

来实现所有需要的数据集和所有实体配置，即复合主键，它只能在

OnModelCreating

覆盖中配置

---

问题是，如果我已经在

MigrationDbContext

中配置了数据模型，并且已经成功地将迁移应用到数据库中，而且数据库的工作就是处理键和索引，那么我是否需要在实际使用的

AppDbContext

或

AppDbContextMySql

中配置模型？换句话说，该模型是仅用于生成迁移脚本，还是在运行时也需要它来帮助EF以任何方式处理数据？

简单的回答是肯定的，在所有情况下都肯定需要该模型

从中生成迁移只是其中一种可能的用法，而且可以肯定的是，主迁移不是可选的功能，可能根本不被使用

该模型的主要目的是提供数据（对象、属性、导航）和存储（数据库表、列和关系）之间的映射。它基本上是ORM（对象关系映射器）的M部分，EF核心是什么

它控制所有EF核心运行时行为—LINQ查询、更改跟踪、CUD等。如关联的表/列名、PK/FK属性/列、级联删除行为、关系的基数等

你问这个问题的方式让我觉得你是在假设模型只用于迁移，而在运行时EF Core从实际数据库获取元数据信息。事实并非如此。对于EF Core，数据库是您在模型配置中告诉他们的内容。根本不检查物理数据库是否同步（正确映射）。这就是为什么当人们搞砸了一些流畅的配置，或者更重要的是，不包括这样的配置时，查询中非退出列会出现错误

这是对单个数据库使用单独（又称“有界”）上下文的主要缺点。因为在派生上下文中使用

DbSet

type属性并不是将实体包含在模型中的唯一方式。事实上，键入的

DbSet

属性只是为了方便起见，只不过是

DbContext.Set（）方法的快捷方式。在模型中包含实体的一种常见（某种隐藏）方法是，当实体被另一个已经包含的实体引用（直接引用或通过集合引用）时。所有这些都是递归的

当实体包含在模型中时，它需要关联的fluent配置，而不考虑具体的上下文类。同样适用于被引用实体及其引用等

因此，我并没有真正看到“有界”上下文类的好处——它们可能适用于与其他对象没有关系的简单自包含对象集（反之亦然），但很容易被这种自动实体包含机制破坏

作为参考，请参见和。
既然您已经解释过了，我也意识到了这一点。EF至少应该能够以某种方式找到（…）一个具有键的实体，因此键仍然应该在某个地方定义。这意味着要么我需要维护两个相似的配置，要么不使用有界DbContexts方法。