C# EF Core 5.0-在更改“文件”时是否需要生成迁移；“定义查询”-映射实体？

我在EF Core 5.0/MS SQL Server数据模型中添加了一个实体类，该类由定义查询（原始SQL查询，在我的数据库中没有对应的表或视图）支持

当我对其进行更改（例如，添加一个新列），然后在Package Manager控制台中运行

Add Migration

以创建迁移步骤时，它会生成一个带有空

Up（MigrationBuilder MigrationBuilder）

和

Down（MigrationBuilder MigrationBuilder）

方法的迁移。但是生成的[MigrationName].Designer.cs文件包含新列，并且my DbContext的ModelSnapshot被修改为包含新列，因此发生了一些变化

我的问题是，我是否需要在每次更改其中一个实体时添加迁移，以使我的应用程序正常运行？如果不需要它们，那么当我更新定义查询支持的实体时，什么被认为是更好的实践：

A.添加这些迁移，即使它们有空白的

Up（MigrationBuilder MigrationBuilder）

和

Down（MigrationBuilder MigrationBuilder）

方法，因为模型已更改，或者

B.不生成迁移，而只是在下次有人做出实际影响底层数据库结构的更改时获取这些更改

代码片段（过度简化以删除标识数据）：

实体类

public class Thing
{
    public int Id { get; set; }

    public string Name { get; set; }
}

实体配置：

public class ThingTypeConfiguration : IEntityTypeConfiguration<Thing>
{
    public void Configure(EntityTypeBuilder<Thing> builder)
    {
        builder
            .HasNoKey()
            .ToView("Dummy") // This is here to work around an issue with the migrations auto-generating a table for the entity - see https://github.com/dotnet/efcore/issues/19972 
            .ToSqlQuery(
            @"SELECT
                [TableName].[IdColumn] AS Id,
                [TableName].[OtherColumn] AS Name
            FROM 
                [TableName]");
    }
}

自动生成的.Designer.cs文件（类的其余部分）：

[DbContext（typeof（MyDbContext））]
[迁移（“20210302175116_MyMigration”）]
部分类MyMigration
{
受保护的覆盖无效BuildTargetModel（ModelBuilder ModelBuilder）
{
#pragma警告禁用612、618
建模者
.HasAnnotation（“关系：MaxIdentifierLength”，128）
.HasAnnotation（“产品版本”、“5.0.3”）
.HasAnnotation（“SqlServer:ValueGenerationStrategy”，SqlServerValueGenerationStrategy.IdentityColumn）；
/*我的模型中所有其他实体的实体配置逻辑*/
实体（“MyDataProject.Thing”，b=>
{
b、 财产（“Id”）
.HasColumnType（“int”）；
b、 财产（“名称”）
.HasColumnType（“nvarchar（max）”）；
b、 ToView（“虚拟”）；
B
.HasAnnotation（“Relational:SqlQuery”，“/*mysql query*/”；
});
#pragma警告恢复612618
}
}

否。如果数据库架构没有更改，则不需要添加新迁移

见鬼，如果新模式与旧模式兼容，您甚至不需要添加新的迁移。例如，删除可选属性仍然是兼容的

---

*.Designer文件只是在生成SQL时偶尔提供有关模型的附加信息。而且，由于迁移不会生成SQL，因此在本例中它完全未使用。

它会生成一个迁移，其中包含清空（MigrationBuilder MigrationBuilder）和向下（MigrationBuilder MigrationBuilder）方法。

--这些方法是否位于分部类中？我不是EF Core迁移方面的专家，但听起来它好像在为您创建这些方法，以便您可以自定义迁移过程。是的，它们位于一个部分类中，其余部分由迁移过程自动生成（并具有所需的更改）。我也不是EF Core的迁移专家！我用一个分部类的例子更新了我的问题。好，这意味着你的新字段位于另一个分部类（生成的那个）中，你就完成了。您所引用的空方法被放置到另一个分部类中，以便重新生成不会删除您放在那里的任何代码。

public class MyDbContext : DbContext
{
    public MyDbContext()
    {
    }

    public MyDbContext(DbContextOptions<MyDbContext> options)
        : base(options)
    {
    }

    public virtual DbSet<Thing> Things { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        if (!optionsBuilder.IsConfigured)
        {
        }
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.ApplyConfigurationsFromAssembly(typeof(MyDbContext).Assembly);
    }
}

public partial class MyMigration : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
    
    }

    protected override void Down(MigrationBuilder migrationBuilder)
    {

    }
}

[DbContext(typeof(MyDbContext))]
[Migration("20210302175116_MyMigration")]
partial class MyMigration
{
    protected override void BuildTargetModel(ModelBuilder modelBuilder)
    {
#pragma warning disable 612, 618
        modelBuilder
            .HasAnnotation("Relational:MaxIdentifierLength", 128)
            .HasAnnotation("ProductVersion", "5.0.3")
            .HasAnnotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn);

        /* Entity configuration logic for all the other entities in my model.. */

        modelBuilder.Entity("MyDataProject.Thing", b =>
            {
                b.Property<string>("Id")
                    .HasColumnType("int");

                b.Property<string>("Name")
                    .HasColumnType("nvarchar(max)");

                b.ToView("Dummy");

                b
                    .HasAnnotation("Relational:SqlQuery", "/* My SQL query */");
            });
#pragma warning restore 612, 618
    }
}