在生产环境下处理EFCore数据库迁移的五种方法

原文链接：https://www.thereformedprogrammer.net/handling-entity-framework-core-database-migrations-in-production-part-1/

作者:Jon P Smith，是《 Entity Framework Core in Action》的作者

安德鲁·洛克（Andrew Lock）撰写了精彩的系列文章《在ASP.NET Core中的应用程序启动时运行异步任务》，其中他以“迁移数据库”为例，介绍了您可以在启动时执行的操作。

在他该系列的第3部分中，他介绍了为什么在启动时迁移数据库并不总是最佳选择。我决定编写一系列有关可以安全迁移数据库的不同方法的系列文章，即使用Entity Framework Core（EF Core）更改数据库的架构。

这是本系列的第一部分，介绍如何创建迁移，而第二部分则介绍如何将迁移应用于数据库，特别是生产数据库。在撰写本文时，我使用了与安德鲁类似的方法，即，我尝试使用EF Core的优点和缺点，一路介绍创建迁移脚本的所有方式。

注意：Andrew和我彼此认识，因为我们同时在为Manning Publications撰写书籍：Andrew的书是“ ASP.NET Core in Action，而我写的书是“ Entity Framework Core in Action ”。我们分享了当作家的辛劳和喜悦，但是安德鲁在ASP.NET Core方面的工作更加艰辛–他的书长700页，而我的书“只有” 500页。

TL; DR –创建迁移的摘要

注意：单击链接可直接转到涵盖该点的部分。

•可以将两种类型的迁移应用于数据库：•添加新的表，列等，称为不间断的更改（简单）。•更改列/表并需要复制数据，称为重大更改（困难）。•有五种方法可以在EF Core中创建迁移•使用EF Core创建迁移-简单，但不能处理所有可能的迁移。•使用EF Core创建迁移，然后手动修改迁移-中到难，但处理所有可能的迁移。•使用第三方迁移构建器来编写C＃迁移-很难，因为您需要自己编写迁移，但是您不需要了解SQL。•使用SQL数据库比较工具比较数据库并输出SQL更改脚本–很简单，但是您确实需要对SQL有一定的了解。•通过复制EF Core的SQL来编写自己的SQL迁移脚本 –很难理解，可以很好地控制，但您确实需要了解SQL。•如何确保您的迁移有效–使用CompareEfSql工具。

场景–关于创建迁移，我们应该问什么问题？

有很多迁移数据库模式的方法，在开发中，几乎可以使用任何方法。但是，当涉及到迁移生产数据库（即实际用户正在使用的数据库）时，它就变得非常严重。弄错了，至少会给您的用户带来不便，并且更糟的是，甚至会丢失您数据库中的（宝贵）数据！

在获得更新数据库模式部分之前，我们需要构建迁移脚本，该脚本将包含模式以及可能的数据更改。要构建适当的迁移脚本，我们需要问自己一些有关需要应用到数据库的更改类型的重要问题。所需的迁移将是：

1.一个非重大更改，也就是说，它只是增加了新的栏目，表格等，这可能而旧的软件仍然运行应用，即旧的软件将与迁移后的数据库一起运行。2.一个重大更改，即有些数据必须复制或迁移过程中转化，无法应用，而旧的软件，即旧的软件会遇到与迁移后的数据库错误（中断服务）。

本文中也介绍了我们正在使用EF Core，它带来的一些好处和限制。好处是，在大多数情况下，EF Core可以自动创建所需的迁移。

约束条件是应用迁移后的数据库必须与EF Core通过查看您的DbContext和映射的类建立的数据库软件模型匹配–我指的是带有大写M的EF Core模型，因为存在一个名为DbContext中的模型，其中包含类和数据库之间的完整映射。

注意：我将介绍迁移，在这些迁移中，您可以控制映射到数据库的类的控制和EF Core配置-有时也称为代码优先方法。

我不会介绍另一种替代方法是，您直接控制数据库，并使用称为 scaffolding的EF Core命令为您创建实体类和EF Core配置。采用这种方法迁移很简单–只需重新搭建数据库即可。

第1部分,创建迁移脚本的五种方法

正如我在上一节中所述，我们创建的任何迁移脚本都必须将数据库迁移到与EF Core Model匹配的状态。例如，如果迁移在表中添加了新列，则映射到该表的实体类必须具有与该新列匹配的属性。如果数据库架构的EF Core的模型确实与数据库匹配，则您可能会在查询或写入中发生错误。如果迁移脚本与该数据库的EF Core模型匹配，则将其称为创建“可用”数据库。

毫无疑问，EF Core创建的迁移的有效性– EF Core创建了它，因此它将是有效的。但是，如果我们需要编辑迁移，或者我们自己进行迁移构建，那么我们需要非常小心，就EF Core而言，迁移会创建一个“可用”数据库。这是我考虑过很多的事情。

这是创建迁移脚本的方法的列表。

•创建C＃迁移脚本1.标准EF Core迁移脚本：使用EF Core的Add-Migration命令创建C＃迁移脚本。2.手动修改的EF Core迁移脚本：使用EF Core的Add-Migration命令创建C＃迁移脚本，然后对其进行手动编辑以添加EF Core遗漏的位。3.使用第三方迁移构建器，例如FluentMigrator。这样的工具使您可以用C＃编写自己的迁移脚本。•创建SQL迁移脚本。1.使用SQL数据库比较工具。它将最后一个数据库架构与EF Core创建的新数据库架构进行比较，并生成一个SQL脚本，该脚本会将旧数据库迁移到新数据库架构。2.编写自己的SQL迁移脚本。称职的SQL编写者可以通过捕获SQL EF Core用来创建数据库的方式来编写SQL迁移脚本。

这是一个摘要图，可让您对这五种方法进行总体回顾，并就其易用性和局限性提出个人看法。

^[1]

现在，让我们依次看一看。

1a,标准EF Core C＃迁移脚本

这是EF Core提供的标准迁移技术。Microsoft官方文档中提供了充分的文档记录^[2]，总而言之，您运行了一个名为Add-Migration的命令，该命令将三个C＃文件添加到您的应用程序，其中包含使用Add-Migration 迁移现有数据库以匹配当前EF Core设置/配置所需的更改。

参考：Microsoft的有关创建迁移的文档^[3]。

1b,手工修改的EF Core C＃迁移脚本

关于EF Core的Add-Migration命令的好处是，它以C＃迁移文件为起点，但是您可以自己编辑这些文件以添加代码来处理重大更改或添加/更新数据库的SQL部分。Microsoft提供了通过复制数据处理重大更改的示例。

参考：Microsoft手动修改迁移的示例^[4]。

1c.使用第三方C＃迁移构建器

安德鲁·洛克（Andrew Lock）向我指出了一种使用FluentMigrator编写迁移的方法。这与EF迁移的工作原理类似，但是您必须完成详细说明更改的所有艰苦工作。好消息是FluentMigrator的命令非常明显。

参考：GitHub的FluentMigrator^[5]。

2a.使用SQL数据库比较工具

有免费的和商业的工具可以比较两个数据库并创建一个SQL更改脚本，该脚本将旧数据库架构迁移到新数据库架构。

Visual Studio 2017（所有版本）中的“视图”选项卡下内置了一个名为“SQL Server Object Explorer”的“免费”比较工具。如果右键单击数据库，则可以访问“比较模式”工具（请参见右图），该工具可以生成SQL更改脚本。

SQL Server的对象资源管理器工具是非常好的，但是没有（可惜）多文档。其他商业系统包括Redgate的SQL Compare。

2b.手工编码SQL迁移脚本

这听起来确实很困难-编写自己的SQL迁移，但是手头上有很多帮助，无论是来自SQL比较工具（参见上文），还是查看SQL EF Core用于创建数据库的帮助。这意味着我可以查看并复制以构建结论SQL迁移脚本的SQL。

您可以捕获EF Core的SQL输出以创建数据库，但是可以在调用方法 EnsureCreated （ EnsureCreated 方法用于创建单元测试数据库）时捕获EF Core的日志记录。因为为EF Core设置日志记录有些复杂，所以我在EfCore.TestSupport库中添加了辅助方法来处理该问题。这是一个示例单元测试，它创建一个新的SQL数据库并捕获EF Core生成的SQL命令。

[RunnableInDebugOnly]publicvoidCaptureSqlEfCoreCreatesDatabaseToConsole(){//SETUPvar options = this.CreateUniqueClassOptionsWithLogging<BookContext>(        log => _output.WriteLine(log.Message));using(var context = newBookContext(options)){
//ATTEMPT        context.Database.EnsureDeleted();        context.Database.EnsureCreated();}}

让我们看一下这段代码的每一行

•第5行。这是一个EfCore.TestSupport方法，为您的DbContext创建选项。此版本使用包含类名的数据库名称。我这样做是因为xUnit测试类是并行运行的，所以我想要此单元测试类的唯一数据库。•第6行。我使用以... WithLogging结尾的选项生成器的版本，该版本允许我捕获日志输出。在这种情况下，我将日志的Message部分直接输出到单元测试输出窗口。•第11和12行。首先，我确保删除数据库，以便在我调用确保创建时，将使用由当前DbContext的配置和映射的类定义的架构来创建一个新的数据库。

以下是在单元测试输出中捕获的部分输出。这为您提供了EF Core用于创建整个架构的确切SQL。您确实只需要提取与迁移有关的部分，但是至少您可以将所需的部分剪切并粘贴到SQL迁移脚本中。

CREATE DATABASE [EfCore.TestSupport-Test_TestEfLogging];ExecutedDbCommand(52ms) [Parameters=[], CommandType='Text', CommandTimeout='60']IF SERVERPROPERTY('EngineEdition') <> 5BEGIN    ALTER DATABASE [EfCore.TestSupport-Test_TestEfLogging] SET READ_COMMITTED_SNAPSHOT ON;END;ExecutedDbCommand(5ms) [Parameters=[], CommandType='Text', CommandTimeout='30']CREATE TABLE [Authors] ([AuthorId] int NOT NULL IDENTITY,[Name] nvarchar(100) NOT NULL,    CONSTRAINT [PK_Authors] PRIMARY KEY ([AuthorId]));ExecutedDbCommand(1ms) [Parameters=[], CommandType='Text', CommandTimeout='30']CREATE TABLE [Books] ([BookId] int NOT NULL IDENTITY,[Title] nvarchar(256) NOT NULL,-- rest of SQL left out

如何确保您的迁移有效–使用CompareEfSql工具

在创建迁移的描述中，我曾多次提到CompareEfSql。该工具将数据库与EF Core首次用于DbContext时创建的数据库模型进行比较。通过DbContext实例中的Model属性访问此模型，是通过查看DbContext配置以及DbSet和DbQuery属性来构建结论EF Core的。

这使开发人员可以根据EF Core Model测试现有数据库，并在错误消息不同的情况下为您提供错误消息。我发现这是一个非常强大的工具，它使我可以手动编码SQL迁移，并确保它们是正确的有一些小限制。这是一个示例单元测试，如果数据库架构与EF Core的模型不匹配，该测试将失败。

[Fact]publicvoidCompareViaContext(){//SETUPvar options = … options that point to the database to check;using(var context = newBookContext(options)){var comparer = newCompareEfSql();
//ATTEMPT//This will compare EF Core model of the database //with the database that the context's connection points tovar hasErrors = comparer.CompareEfWithDb(context);
//VERIFY//The CompareEfWithDb method returns true if there were errors.//The comparer.GetAllErrors property returns a string//where each error is on a separate line        hasErrors.ShouldBeFalse(comparer.GetAllErrors);}}

我喜欢这个工具，它位于EFCore.TestSupport开源库中。它使我能够构建迁移，并确保它们能够正常工作。我也将其作为正常的单元测试来运行，它会立即告诉我是否是我或另一个同事更改了EF Core的设置。

您可以在名为EF Core的文章中获得对该工具的更详细的描述：完全控制数据库模式及其许多功能和配置可以在CompareEfSql文档页面中找到^[7]。

注意：我最初是为EF6.x构建此版本的（请参阅此旧文章），但是由于EF6.x并未完全公开其内部模型而受到限制。

有了EF Core，我可以做更多的事情，现在我可以检查几乎所有内容，并且因为我利用了EF Core的脚手架服务，所以它适用于EF Core支持的任何数据库。

结论–第1部分

本系列的这一部分将介绍如何创建有效的迁移，而第二部分则涉及将迁移应用于数据库。本文列出了使用EF Core时用于创建数据库迁移的所有适用方法-优缺点。如您所见，EF Core的Add-Migration命令确实很好，但是并不能涵盖所有情况。

由您决定要遇到的迁移类型，以及您希望对数据库架构进行何种级别的控制。如果您仅使用EF Core的标准迁移（1a）就可以摆脱困境，那么这将使您的生活更轻松。但是，如果您预期会发生重大变化，或者需要设置额外的SQL功能，那么您现在知道可用的选项。

令人担心的部分出现在part2中-将迁移应用于生产数据库。更改包含关键业务数据需求（需求！）的数据库，请仔细计划和测试。您需要考虑如果（何时！）迁移因错误而失败时该怎么办。

我放弃EF6中的EF迁移的最初原因是它在启动时自动迁移运行良好，但它在部署时引发错误！而且很难找到迁移中的错误-仅此一项就使我远离使用EF迁移（要获得更多信息，可以查看这篇老文章^[8]）。

EF Core的迁移处理要比EF6更好：已可以实现自动迁移，并且EF Core迁移对git-merge更加友好，仅提及两个更改。

而且，我构建SQL迁移脚本的方式使我比正在运行Add-Migration时要更加仔细地思考自己在做什么。EF Core是一个非常出色的O / RM，有时确实有许多隐藏功能。创建SQL迁移脚本使我从数据库的角度考虑了迁移问题，而且我经常会对数据库和C＃代码的一些细微调整，以使数据库更好的运行。

References

[1] 充分的文档记录: https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/

[2] Microsoft的有关创建迁移的文档: https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/#create-a-migration
[3] Microsoft手动修改迁移的示例: https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/#customize-migration-code
[4] GitHub的FluentMigrator: https://github.com/fluentmigrator/fluentmigrator
[5]:https://www.thereformedprogrammer.net/wp-content/uploads/2019/01/SQLServerObjectExplorerCompareSchema.png

[6] CompareEfSql文档页面中找到: https://github.com/JonPSmith/EfCore.TestSupport/wiki/9.-EfSchemaCompare
[7] 老文章: https://www.thereformedprogrammer.net/handling-entity-framework-database-migrations-in-production-part-1-applying-the-updates/