[[438324]]

在生產中運用EFCore的模式實戰

這是使用EF Core遷移數據庫的系列文章中的第二篇。本文著眼于將遷移應用于數據庫，并從第1部分開始，該部分介紹了如何創建遷移腳本。如果您還沒有閱讀第1部分，那么本文的某些部分將毫無意義，因此這里是第1部分的快速回顧。

可以將兩種類型的遷移應用于數據庫：

• 添加新的表，列等，稱為不間斷的更改(簡單)。
• 更改列/表并需要復制數據，這稱為重大更改(困難)。
• 將遷移應用于數據庫的主要方法有兩種
• 使用EF Core遷移功能
• 使用EF Core創建遷移，然后手動修改遷移。
• 使用第三方遷移構建器在C#中編寫遷移。
• 使用SQL數據庫比較工具比較數據庫并輸出SQL更改腳本。
• 通過復制EF Core的SQL編寫自己的SQL遷移腳本。

因此，既然您現在知道如何創建遷移腳本，那么我將研究可以將遷移應用于生產數據庫的不同方式，以及這些方式所具有的利弊。

TL; DR –內容摘要

注意：單擊鏈接可直接轉到涵蓋該點的部分。

• 您具有影響遷移方法可以使用的應用程序的類型。?您必須考慮可能發生的錯誤并制定計劃。?有四種方法可以將遷移應用于數據庫
• 在啟動時調用context.Database.Migrate()Very Easy，但是存在一些嚴重的問題，限制了它的實用性。
• 通過控制臺應用程序調用context.Database.Migrate()-Easy，并且效果很好，尤其是在部署管道中
• 將EF Core遷移輸出為SQL腳本并在目標數據庫上執行該腳本 -Hard，但是卻能提供很好的控制。
• 使用數據庫遷移應用程序工具來應用您自己的SQL腳本 -Hard，但是您卻可以很好地控制。
• 應用遷移的三個不同級別。
• 在遷移數據庫時停止應用程序是最安全的選擇，但并非總是可能的。
• 在應用程序運行時，可以將某些(但不是全部)不間斷的更改應用于數據庫。
• 對于連續服務應用程序(7*24小時運行的服務)，要應用重大更改需要五個步驟。

場景分析–您的產品是哪種應用程序?

在第1部分中，我們著重于創建“有效”的遷移，以及遷移是不間斷的變更還是重大變更(請參閱本文開頭的快速定義，或第1部分中的此鏈接。

現在，我們正在考慮將遷移應用于數據庫，但是我們擁有的選項取決于正在訪問數據庫的一個或多個應用程序。這是您需要考慮的問題。

1.是只有一個應用程序訪問該數據庫，還是您的應用程序是橫向擴展的Web應用程序，即，同時運行多個版本的應用程序。如果您的應用程序是橫向擴展，則將刪除其中一個選項。2.您可以在將遷移應用到數據庫時停止應用程序，還是您的應用程序提供7*24小時連續服務?在應用重大變更方面，更新連續服務應用程序會帶來一些挑戰。

在遷移生產數據庫時，有點偏執是可以的。

正如我在第1部分末尾所說的那樣-當您將遷移應用于生產數據庫時，最恐怖的部分到來了。更改包含關鍵業務數據需求(需求!)的數據庫，請仔細計劃和測試。您需要考慮如果(何時!)遷移因錯誤而失敗時該怎么辦。

在考慮應用遷移的不同方法時，您應該腦海中浮現“如果有錯誤會發生什么?”。這可能會促使您采用更復雜的遷移方法，因為它更易于測試或還原。我不能為您提供規則或建議，因為每個系統都不同，但是對故障有點偏執并不是一件壞事。我應該讓您構建一個更健壯的用于遷移應用程序及其數據庫的系統。

第2部分：如何將遷移應用于數據庫。

下面的列表提供了將遷移應用于數據庫的不同方法。我列出了EF Core案例的三個選項：第一個是最簡單的，但是它有其他兩個選項所沒有的限制。SQL遷移沒有實際限制，但確實需要數據庫遷移應用程序工具才能以正確的順序應用SQL腳本。

這是您可以應用遷移的方法列表。

1.EFCore遷移

• 在啟動時調用context.Database.Migrate()
• 通過控制臺應用程序或管理命令調用context.Database.Migrate()
• 將遷移輸出作為SQL腳本輸出，然后在目標數據庫上執行該腳本。

2.SQL遷移

使用數據庫遷移應用程序工具。

最后，如何應用遷移取決于遷移類型(中斷或不中斷)和要更新的應用程序類型(單個應用程序，并行運行的多個應用程序或必須停止的應用程序)。這是所有這些排列的圖表。

外部的深藍色表示可以在所有情況下都應用SQL遷移，而內部較淺的方框表示可以在其中添加不同類型的EF Core遷移。以下是有關該圖的一些澄清說明：

• 該圖顯示了標準EF遷移和手工修改的EF遷移，但是當我談論應用遷移時，兩者之間沒有區別-我們很簡單地應用EF Core遷移。?圖中的“五個階段的應用程序更新”紅色框表示您需要對無法停止的應用程序進行重大更改所需要的復雜階段。我將在文章末尾介紹。

現在，我將詳細介紹應用遷移的每種方式。

1a。在啟動時調用context.Database.Migrate()

到目前為止，這是應用遷移的最簡單方法，但是它有一個很大的局限性–您不應同時運行Migrate方法的多個實例。如果橫向擴展Web應用程序，則可能會發生這種情況。引用安德魯·洛克(Andrew Lock)的話：“

我們不能保證這會給您帶來麻煩，但是除非您非常謹慎地確保冪等更新和錯誤處理，否則您很可能會陷入困境

” –請參閱他的帖子的這一部分“ 在ASP.NET Core中的應用啟動時運行異步任務[1] ”。

1b。通過控制臺應用程序或管理命令調用context.Database.Migrate()

如果您不能并行運行多個Migrate方法，那么確保此方法的一種方法是在設計為僅執行Migrate方法的獨立應用程序內調用Migrate方法。您可以在主Web應用程序解決方案中添加一個控制臺應用程序項目，該項目可以訪問DbContext并可以調用Migrate。您既可以自己運行它，也可以讓您的部署系統運行它(EF6.x用戶注意–這等效于運行Migrate.exe，但其中已編譯應用程序dll)。

1c。將EF Core遷移轉換為腳本并將其應用于數據庫

通過使用腳本遷移命令EF Core會將特定的遷移或默認情況下的所有遷移轉換為SQL腳本。然后，您可以使用可以在要更新的特定數據庫上執行SQL的方法來應用此方法。您可以在SQL Server Management Studio中手動執行SQL ，但是通常您的發布管道中有一些內容可以在適當的時間執行。

2a。使用遷移工具應用SQL腳本

如果創建了一系列SQL遷移腳本，則需要以下步驟：a)以正確的順序應用它們，b)僅應用一次。EF Core的遷移包含執行“正確順序”和“僅一次”規則的代碼，但是當我們編寫自己的遷移腳本時，我們需要一個可以提供這些功能的工具。

我和其他許多人使用了一個名為DbUp的開源庫，該庫提供了這些功能(以及更多功能)，還支持多種數據庫類型。我按字母順序排列遷移腳本，例如“ Script0001 –初始遷移”，“ Script0002 –添加種子數據”以供DbUp應用。就像EF Core遷移一樣，DbUp使用一個表來列出哪些遷移已應用到數據庫，并且僅在該表中沒有遷移時才應用。

還可以使用其他遷移工具，例如Octopus Deploy和各種RedGate工具(但我沒有使用過它們，因此請檢查它們是否具有正確的功能)。

應用程序和應用程序遷移

將遷移應用于數據庫時，可以停止應用程序，或者在某些情況下可以在遷移運行時應用遷移。在本節中，我將介紹為您提供的不同選項。

1.在遷移數據庫時停止應用程序

這是最安全的選項，可與重大更改和不中斷更改一起使用，但是您的用戶和您的業務可能并不那么滿意。我稱其為“維護站點”。在“站點關閉”方法中，您不想在用戶輸入數據或完成訂單時停止應用程序。這就是您或您的公司獲得不良聲譽的方式。

我早在2015年就遇到了這個問題，并且我創建了一種方法來警告人們該網站將要關閉，然后停止除管理員以外的所有人員訪問該應用程序。我之所以選擇這種方法，是因為對于正在使用的Web應用程序，此方法比支持破壞性更改同時保持Web應用程序運行的開銷要小(我將在稍后介紹對連續服務應用程序進行中斷)。通常在周末和晚上，您可能會遇到所使用服務的“此站點已關閉維護”。

注意：我寫了一篇名為“ 如何使ASP.NET MVC網站“為了維護而停機 ””的文章，您可能希望看一下-該代碼是針對ASP.NET MVC5的，因此需要一些工作才能使其正常工作。.NET Core，但該想法仍然有效。

在應用程序運行時應用不間斷的遷移

從理論上講，通過不間斷的更改，您可以在舊應用程序運行時將其應用于數據庫，但是有些問題可能會讓您失望。例如，如果您添加了一個沒有SQL默認值且不知道該新列的舊軟件的新的非空列，并嘗試插入新行，則您會收到一條SQL錯誤，因為舊軟件沒有提供了非空列的值。

但是，如果您知道不間斷的遷移沒有問題，那么在舊應用程序運行時應用遷移將為您的用戶提供連續的服務。有多種方法可以執行此操作，具體取決于您選擇了哪種遷移應用程序方法，想到的就是Azure的暫存槽(已經存在了很長時間)和更新的Azure Pipelines。

將重大更改應用于連續運行的應用程序：五階段的應用程序更新。

最困難的工作是對不斷運行的應用程序進行重大更改。在顯示不同方法的圖表中，右上方會顯示一個名為“五階段應用程序更新”的紅色框。該名稱來自以下事實：您需要分階段遷移，通常為五個階段，如下圖所示。

注意：安德魯·洛克(Andrew Lock)稱贊我在上一節中描述的“添加不可為空的列”問題可以分三個階段處理：a)添加新列但可為空，b)部署已知該列的新軟件，以及c)將列更改為不可為空。

這是我的《EFCore》一書的第11.5.3節中的圖表，該圖顯示了添加重大更改所需的五個階段，這些更改將現有的CustomerAndAddress表分為兩個表，Customers和Addresses。

如您所見，這樣的更新創建起來很復雜，應用起來也很復雜，但這就是運行連續系統的成本。這五個階段沒有任何真正的替代方案，除了您永遠不要對連續運行的系統應用重大更改(我聽說有人說這是他們的方法)。

注意：我在我的書“ Entity Framework Core in Action[4] ”的11.5.3節中介紹了持續的，五個階段的應用程序更新，您還可以在Neil Ford的“ Building Evolutionary Architectures ” 一書的第5章中找到有關此內容的內容。等。

結論

如果數據庫中的數據和服務的可用性對組織很重要，那么您必須認真對待數據庫遷移。在第1部分中，我介紹了創建遷移腳本的不同方法，并且本文介紹了如何將這些遷移應用于生產數據庫。本系列文章的目的是為您提供各種選擇，以及它們的優缺點，以便您可以就如何處理遷移做出明智的決定。

就像我在第一篇文章中所說的那樣，我與EF遷移的第一個磨合是使用EF6。我非常了解EF6，并且寫過《 Entity Framework Core in Action》一書，[5]我對EF Core的了解甚至更好。圍繞遷移從EF6到EF Core的變化代表了EF Core中整個方法的變化。

EF6進行了很多“魔法”操作，使其更易于使用- 啟動時自動遷移就是其中之一。問題是，當EF6的“魔法”效果不佳時，很難對其進行梳理。EF Core的遷移方法是由您決定如何在何處以及如何使用它-沒有自動的“魔法”。EF Core遷移的許多其他小變化來自于聆聽EF4到6的用戶。

因此，在生產數據庫上的遷移令人恐懼。我已經為您提供了一些有關選項的見解，但這僅是更改生產數據庫的最低要求。需要根據需要添加備份，策略，產品前測試和部署管道，以構建可靠的系統。

祝你能享受編碼的快樂!

References

[1] 在ASP.NET Core中的應用啟動時運行異步任務: https://andrewlock.net/running-async-tasks-on-app-startup-in-asp-net-core-part-1/

[2] 選項: https://andrewlock.net/running-async-tasks-on-app-startup-in-asp-net-core-part-1/#4-manually-running-tasks-in-program-cs

[3] 本示例: https://github.com/JonPSmith/EfCore.GenericServices/blob/master/RazorPageApp/Program.cs

[4] Entity Framework Core in Action: http://bit.ly/2m8KRAZ

[5] ，: http://bit.ly/2m8KRAZ

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

作者：Jon P Smith