Entity Framework Core 在底层利用大量注入服务来处理迁移。
在 C# 包中,似乎没有公开任何“表面级别”配置来应用逻辑,将创建的迁移的迁移文件夹指定为默认值。
我知道您可以通过
-o
上的 Add-Migration
标志指定输出文件夹,但这每次都涉及手动过程。
我很想知道是否有人设法找到实际解析当您调用
Add-Migration
时迁移将去往的文件夹的特定服务,并设法找到一种方法来覆盖它的行为以添加自定义逻辑使输出文件夹更加具体。
就我而言,我想将我的迁移输出到
<MyProject>/Data/Migrations/Year/Month/
的路径,任何维护了更长运行时间的项目的人都可以证明,将所有迁移转储到单个文件夹的默认设置最终可能会变得非常笨拙,因为列表变得非常长(最糟糕的是,您最关心的迁移往往位于该列表的底部)
我见过一些项目在同一个文件夹中有多个数百个迁移 .cs 文件,在一个完全无组织的目录中筛选是非常令人沮丧的。
能够自动化将迁移文件输出到
/year/month/
架构形式的过程将非常有帮助。
注意:我承认这可能可以通过某种 Powershell cmdlet 或其他方式来实现,但这需要开发人员拥有额外的入门知识共享,并且他们需要知道要运行的特定命令。
而如果通过 C# 覆盖服务以“正常工作”的形式处理逻辑,则不需要额外的知识共享,并且将删除另一个加速步骤。
任何曾经使用过原始开发人员 8 年前离开的遗留代码库的人肯定都能理解将这种自动化“融入”到应用程序核心代码中的愿望,而不是依赖于外部脚本/cmdlet他们必须去寻找。
我安装了 Nuget 包
Microsoft.EntityFrameworkCore.Design
,根据文档,它应该具有界面 IMigrationsScaffolder
它看起来像是脚手架和删除迁移的主要入口点,根据此处的文档:https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.migrations.design.imigrationsscaffolder?查看=efcore-7.0
但是,即使在安装了该包之后,它似乎并未在程序集中实际包含该接口,任何在命名空间(或低于该名称空间的任何内容)内部定位它的尝试都会失败,Visual Studio 无法识别该接口,然而“在 nuget 上搜索这种类型”仍然指向该 nuget 包。
v7.0.12 的 Nuget Package explore 似乎表明该文件存在并在程序集中声明: https://nuget.info/packages/Microsoft.EntityFrameworkCore.Design/7.0.12Microsoft.EntityFrameworkCore.Migrations.Design
,Visual Studio 会抱怨它无法识别该命名空间(特别是
Microsoft.EntityFrameworkCore.Migrations.Design
部分)这很奇怪,我以前从未见过这种行为,根据 Visual Studio,Nuget 包的一部分似乎实际上并不存在。
.Design
的方式
Microsoft.EntityFrameworkCore.Design
很重要:IncludeAssets