c# - 对于运行时数据库上下文，我是否需要 OnModelCreating 中的实体数据模型？

Question

所以，我以下列方式使用 EF DbContexts。一个AppDbContext是派生自 的抽象类DbContext，它包含我的 DbSet 并用作注入服务的类型。它的“实现”就像AppDbContextMySql，这​​是不言自明的 - 它源自AppDbContext并处理与实际数据库的连接。可以有几个这样的抽象/实现对来分隔数据表，但通常，它们都指向同一个实际的数据库实例。

然后我需要全部迁移，所以我添加了一个MigrationDbContext实现所有数据集和所有需要的实体配置，即只能在OnModelCreating覆盖中配置的复合主键。

问题是，如果我已经有数据模型配置MigrationDbContext，并且已经成功地将迁移应用到数据库，并且无论如何处理键和索引是数据库的工作，我是否需要在我的实际使用中使用模型AppDbContext配置AppDbContextMySql？换句话说，模型是否仅用于生成迁移脚本，还是在运行时也需要它来帮助 EF 以任何方式处理数据？

标签： c#.net-coreentity-framework-core

Answer 1

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

从中生成迁移只是可能的用途之一，并且肯定不是主要的 - 迁移是可能根本不会使用的可选功能。

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

它控制所有 EF Core 运行时行为 - LINQ 查询、更改跟踪、CUD 等。比如关联的表/列名称是什么、PK/FK 属性/列是什么、级联删除行为是什么、基数是什么关系和许多其他人。

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

这是为单个数据库使用单独（又名“有界”）上下文的主要缺点。因为在派生上下文中具有DbSet类型属性并不是将实体包含在模型中的唯一方式。事实上，类型化DbSet属性只是为了方便，只不过是方法的快捷DbContext.Set<T>()方式。在模型中包含实体的一种常见（一种隐藏）方法是当另一个已包含的实体（直接或通过集合）引用它时。所有这些都是递归的。

并且当实体包含在模型中时，无论具体的上下文类如何，它都需要关联的流畅配置。对于引用的实体及其引用等也是如此。

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

有关参考，请参阅在模型中包含类型和创建和配置模型。