如何在消费环境下用好EFCore

在消费中运用EFCore的形式实战

这是经常使用EFCore迁徙数据库的系列文章中的第二篇。本文着眼于将迁徙运行于数据库，并从第1局部开局，该局部引见了如何创立迁徙脚本。假设您还没有浏览第1局部，那么本文的某些局部将毫有意义，因此这里是第1局部的极速回忆。

可以将两种类型的迁徙运行于数据库：

因此，既然您如今知道如何创立迁徙脚本，那么我将钻研可以将迁徙运行于消费数据库的不同形式，以及这些形式所具备的利害。

TL; DR –内容摘要

留意：单击链接可间接转到涵盖该点的局部。

场景剖析–您的产品是哪种运行程序?

在第1局部中，咱们着重于创立“有效”的迁徙，以及迁徙是不连续的变卦还是严重变卦(请参阅本文扫尾的极速定义，或第1局部中的此链接。

如今，咱们正在思考将迁徙运行于数据库，然而咱们领有的选项取决于正在访问数据库的一个或多个运行程序。这是您须要思考的疑问。

1.是只要一个运行程序访问该数据库，还是您的运行程序是横向裁减的Web运行程序，即，同时运转多个版本的运行程序。假设您的运行程序是横向裁减，则将删除其中一个选项。2.您可以在将迁徙运行到数据库时中止运行程序，还是您的运行程序提供7*24小时延续服务?在运行严重变卦方面，降级延续服务运行程序会带来一些应战。

在迁徙消费数据库时，有点偏执是可以的。

正如我在第1局部末尾所说的那样-当您将迁徙运行于消费数据库时，最恐惧的局部来到了。更改蕴含关键业务数据需求(需求!)的数据库，请细心方案和测试。您须要思考假设(何时!)迁徙因失误而失败时该怎样办。

在思考运行迁徙的不同方法时，您应该脑海中显现“假设有失误解出现什么?”。这或许会促使您驳回更复杂的迁徙方法，由于它更易于测试或恢复。我不能为您提供规定或倡导，由于每个系统都不同，然而对缺点有点偏执并不是一件坏事。我应该让您构建一个更强健的用于迁徙运行程序及其数据库的系统。

第2局部：如何将迁徙运行于数据库。

上方的列表提供了将迁徙运行于数据库的不同方法。我列出了EFCore案例的三个选项：第一个是最便捷的，然而它有其余两个选项所没有的限度。SQL迁徙没有实践限度，但确实须要数据库迁徙运行程序工具才干以正确的顺序运行SQL脚本。

这是您可以运行迁徙的方法列表。

1.EFCore迁徙

2.SQL迁徙

经常使用数据库迁徙运行程序工具。

最后，如何运行迁徙取决于迁徙类型(终止或不终止)和要降级的运行程序类型(单个运行程序，并行运转的多个运行程序或必定中止的运行程序)。这是一切这些陈列的图表。

外部的深蓝色示意可以在一切状况下都运行SQL迁徙，而外部较浅的方框示意可以在其中减少不同类型的EF Core迁徙。以下是无关该图的一些廓清说明：

如今，我将详细引见运行迁徙的每种形式。

1a。在启动时调用context.Database.Migrate()

到目前为止，这是运行迁徙的最简双方法，然而它有一个很大的局限性–您不应同时运转Migrate方法的多个实例。假设横向裁减Web运行程序，则或许会出现这种状况。援用安德鲁·洛克(AndrewLock)的话：“

咱们不能保障这会给您带来费事，然而除非您十分审慎地确保幂等降级和失误处置，否则您很或许会堕入困境

” –请参阅他的帖子的这一局部“ 在ASP.NET Core中的运行启动时运转异步义务[1] ”。

好处	·相对容易成功（请参阅揭示） ·确保在运行程序运转之前数据库是最新的。
坏处	·不得并行运转两个或多个Migrate方法。·假设迁徙有失误，则您的运行程序将无法用。·难以诊断启动失误
局限性	不适用于延续服务系统
揭示	我十分青睐Andrew Lock的文章中的在启动时运转迁徙的。我在一些经常使用内存数据库的演示系统中经常使用了相似的方法，这些数据库须要初始化（请参见）
我的倡导	假设您正在运转单个Web运行程序或相似的Web运行程序，并且可以在没有人经常使用它的状况下降级系统，那么这或许对您有用。我没有像我经常使用的许多系统那样经常使用横向裁减。

1b。经过控制台运行程序或治理命令调用context.Database.Migrate()

假设您不能并行运转多个Migrate方法，那么确保此方法的一种方法是在设计为仅口头Migrate方法的独立运行程序内调用Migrate方法。您可以在主Web运行程序处置方案中减少一个控制台运行程序名目，该名目可以访问DbContext并可以调用Migrate。您既可以自己运转它，也可以让您的部署系统运转它(EF6.x用户留意–这等效于运转Migrate.exe，但其中已编译运行程序dll)。

好处	·它适用于一切状况。·与部署系统配合良好。
坏处	还有更多上班。
局限性	–无–，但请留意继续启动的五阶段运行程序降级
揭示	假设您的控制台运行程序经常使用衔接字符串来定义要将迁徙运行到哪个数据库，那么它将更易于在部署管道中经常使用。
我的倡导	假设您具备部署管道，那么这是一个不错的选用，由于您可以在部署环节中口头控制台运行程序。假设您是手动运行迁徙，则有命令Update-Database。

1c。将EF Core迁徙转换为脚本并将其运行于数据库

经过经常使用脚本迁徙命令EFCore会将特定的迁徙或自动状况下的一切迁徙转换为SQL脚本。而后，您可以经常使用可以在要降级的特定数据库上口头SQL的方法来运行此方法。您可以在SQLServer Management Studio中手动口头SQL ，然而通常您的颁布管道中有一些内容可以在适当的期间口头。

好处	·它适用于一切状况。·与可以经常使用SQL脚本的部署系对抗同很好地上班。·您可以在运转SQL之前先检查它，看看它能否反常。
坏处	·比控制台运行程序（1b）更多的上班 ·您须要一些运行程序将脚本运行于正确的数据库。
局限性	–无–，但请留意继续启动的五阶段运行程序降级
揭示	SQL蕴含用于降级迁徙历史记载的代码，然而您必定在Script-Migration命令中包括idempotent选项，以失掉阻止两次运行迁徙的审核。
我的倡导	假设您想经常使用EF Core的Migrate方法，那么我倡导您经常使用控制台运行程序1b。它与经常使用脚本一样安保，并且口头相反的上班。然而，假设您的管道曾经可以经常使用SQL更改脚本，那么这十分适宜您。

2a。经常使用迁徙工具运行SQL脚本

假设创立了一系列SQL迁徙脚本，则须要以下步骤：a)以正确的顺序运行它们，b)仅运行一次性。EFCore的迁徙蕴含口头“正确顺序”和“仅一次性”规定的代码，然而当咱们编写自己的迁徙脚本时，咱们须要一个可以提供这些性能的工具。

我和其余许多人经常使用了一个名为DbUp的开源库，该库提供了这些性能(以及更多性能)，还允许多种数据库类型。我按字母顺序陈列迁徙脚本，例如“Script0001 –初始迁徙”，“ Script0002 –减少种子数据”以供DbUp运行。就像EFCore迁徙一样，DbUp经常使用一个表来列出哪些迁徙已运行到数据库，并且仅在该表中没有迁徙时才运行。

还可以经常使用其余迁徙工具，例如Octopus Deploy和各种RedGate工具(但我没有经常使用过它们，因此请审核它们能否具备正确的性能)。

好处	·它适用于一切状况。与部署系统配合良好。
坏处	·您必定治理脚本。
局限性	–无–，但请留意继续启动五阶段运行程序降级
* 揭示 * （适用于DbUp）	·我制造了一个控制台运行程序，该运行程序接受衔接字符串，而后运转DbUp，因此可以在部署管道中经常使用它。·为了启动测试，我使运转DbUp的方法在“仅以调试形式运转”单元测试中可用于我的单元测试程序集，该方法经常使用我的CompareEfSql工具正确迁徙了本地数据库（请参阅本系列第1局部中无关测试迁徙的局部。
我的倡导	经常使用EF Core的名目上经常使用这种方法。

运行程序和运行程序迁徙

将迁徙运行于数据库时，可以中止运行程序，或许在某些状况下可以在迁徙运转时运行迁徙。在本节中，我将引见为您提供的不同选项。

1.在迁徙数据库时中止运行程序

这是最安保的选项，可与严重更改和不终止更改一同经常使用，然而您的用户和您的业务或许并不那么满意。我称其为“保养站点”。在“站点封锁”方法中，您不想在用户输入数据或成功订单时中止运行程序。这就是您或您的公司取得不良声誉的形式。

我早在2年就遇到了这个疑问，并且我创立了一种方法来正告人们该网站将要封锁，而后中止除治理员以外的一切人员访问该运行程序。我之所以选用这种方法，是由于关于正在经常使用的Web运行程序，此方法比允许破坏性更改同时坚持Web运行程序运转的开支要小(我将在稍后引见对延续服务运行程序启动终止)。通常在周末和早晨，您或许会遇到所经常使用服务的“此站点已封锁保养”。

留意：我写了一篇名为“ 如何使ASP.NET MVC网站“为了保养而停机 ””的文章，您或许宿愿看一下-该代码是针对ASP.NETMVC5的，因此须要一些上班才干使其反常上班。.NET Core，但该想法依然有效。

在运行程序运转时运行不连续的迁徙

从通常上讲，经过不连续的更改，您可以在旧运行程序运转时将其运行于数据库，然而有些疑问或许会让您绝望。例如，假设您减少了一个没有SQL自动值且不知道该新列的旧软件的新的非空列，并尝试拔出新行，则您会收到一条SQL失误，由于旧软件没有提供了非空列的值。

然而，假设您知道不连续的迁徙没有疑问，那么在旧运行程序运转时运行迁徙将为您的用户提供延续的服务。有多种方法可以口头此操作，详细取决于您选用了哪种迁徙运行程序方法，想到的就是Azure的暂存槽(曾经存在了很常年间)和降级的AzurePipelines。

将严重更改运行于延续运转的运行程序：五阶段的运行程序降级。

最艰巨的上班是对不时运转的运行程序启动严重更改。在显示不同方法的图表中，右上方会显示一个名为“五阶段运行程序降级”的白色框。该称号来自以下理想：您须要分阶段迁徙，通常为五个阶段，如下图所示。

留意：安德鲁·洛克(AndrewLock)美化我在上一节中形容的“减少无法为空的列”疑问可以分三个阶段处置：a)减少新列但可为空，b)部署已知该列的新软件，以及c)将列更改为无法为空。

这是我的《EFCore》一书的第11.5.3节中的图表，该图显示了减少严重更改所需的五个阶段，这些更改将现有的CustomerAndAddress表分为两个表，Customers和Addresses。

如您所见，这样的降级创立起来很复杂，运行起来也很复杂，但这就是运转延续系统的老本。这五个阶段没有任何真正的代替方案，除了您永远不要对延续运转的系统运行严重更改(我据说有人说这是他们的方法)。

留意：我在我的书“ Entity Framework Core in Action[4]”的11.5.3节中引见了继续的，五个阶段的运行程序降级，您还可以在Neil Ford的“ Building EvolutionaryArchitectures ” 一书的第5章中找到无关此内容的内容。等。

论断

假设数据库中的数据和服务的可用性对组织很关键，那么您必定仔细看待数据库迁徙。在第1局部中，我引见了创立迁徙脚本的不同方法，并且本文引见了如何将这些迁徙运行于消费数据库。本系列文章的目的是为您提供各种选用，以及它们的优缺陷，以便您可以就如何处置迁徙做出理智的选择。

就像我在第一篇文章中所说的那样，我与EF迁徙的第一个磨合是经常使用EF6。我十分了解EF6，并且写过《 Entity Framework Core inAction》一书，[5]我对EF Core的了解甚至更好。围绕迁徙从EF6到EF Core的变动代表了EF Core中整个方法的变动。

EF6启动了很多“魔法”操作，使其更易于经常使用- 启动时智能迁徙就是其中之一。疑问是，当EF6的“魔法”成果不佳时，很难对其启动梳理。EFCore的迁徙方法是由您选择如何在何处以及如何经常使用它-没有智能的“魔法”。EF Core迁徙的许多其余小变动来自于倾听EF4到6的用户。

因此，在消费数据库上的迁徙令人恐惧。我曾经为您提供了一些无关选项的见地，但这仅是更改消费数据库的最低要求。须要依据须要减少备份，战略，产品前测试和部署管道，以构建牢靠的系统。

祝你能享用编码的快乐!

References

[1] 在ASP.NET Core中的运行启动时运转异步义务:

[2] 选项:

[3] 本示例:

[4] Entity Framework Core in Action:

[5] ，:

原文链接：

作者：Jon P Smith