關於EF中使用Migrations的一些小提示

在運行正常的狀況下，EF的數據遷移功能很是強大。可是當它出現情況時，試圖找到問題發生的緣由時一般都很讓人鬱悶（無法調試，提示信息很模糊等等緣由）。我花了不少時間來確保在個人遷移能工做正常，而後我整理了一些經驗給你們分享一下:

1. 不要使用自動遷移（Automatic Migrations）

   自動遷移很適合演示環境或者快速驗證模型等，可是在生產環境中就不太適合了。如下是否是用自動遷移的一些緣由：

   1. 自動遷移不能產生惟一標示，因此兩次遷移過程當中不能產生差別化腳本，也就不能應用於其餘環境，尤爲是生產環境須要使用腳本進行遷移的時候。
   2. 自動遷移不會顯示數據庫發生了什麼更改，也不提供單獨的備份方法。
   3. Automatic Migrations are applied using the same ‘Update-Database’ command that also runs the Code-Based migrations (side effect free!). When mixing Automatic and Code-based migrations a simple ‘Update-Database’ to run Code-based migrations may also generate Automatic ‘ghost’ scripts against the database.

   下面是如何關閉自動遷移的方法：

2. 瞭解_MigrationHistory 表（啓用遷移後在數據庫中自動生成的遷移歷史記錄表）

   _MigrationHistory表提供了有關數據庫的元數據，最重要的是它顯示了那些遷移已經應用。在某些時候須要手動從這裏刪除記錄，默認狀況下它是一個系統表，但能夠進行其餘配置

3. 遷移並非只能「升」，它也能「降」

   每個遷移都有相應的升級或者降級的概念，當升級的時候，數據庫將會應用遷移，當降級的時候，目標數據庫會撤銷相應的遷移。瞭解降級時目標數據庫中結構和數據發生了什麼和升級同樣重要，保險起見，應該把它做爲一項應急計劃，確保發生問題能夠輕鬆處理。

4. 若是你想從新生成遷移計劃（「re-scaffold」），確保先撤銷遷移。

   ‘Re-scaffolding’將會從新產生現有遷移的內容並添加一些新的改動進去。

   若是遷移已經應用到數據庫，那必須先撤銷遷移，而後再從新生成遷移文件。（使用update-database -target:xxxMigrationName）。若是沒有撤銷，遷移文件將會被修改，下次數據庫遷移就會出現問題（可能就無法回退了）

5. 絕對不要再撤銷遷移以前，刪除遷移文件。

   首先遷移是能夠回退版本的，若是在撤銷遷移以前刪除遷移文件，數據庫將陷入無效狀態。若是在後續繼續添加遷移文件，可能會產生遷移問題（好比，新的遷移文件包含上一次遷移到內容，執行update-databse時會提示，更改已經存在）

6. 瞭解數據表關聯處理（包括Fluent API）

   下面的代碼很難理解麼?

   對我來講是的。不管如何配置數據表之間關係的時候必定要了解Fluent API的相關知識，能夠在下文學習 configure the correct relationship

7. 查看遷移代碼

   爲何？難道是生成的遷移代碼有問題麼？其實並非。我在每次生成都要之後檢查一下遷移文件，大多時候只是確保是關係配置的是否正確或者有沒有遺漏了什麼。

8. 完全恢復到初始狀態，而後再回來

   常常檢查一下遷移文件與數據庫是否匹配，它們是否健康。一個方法是撤銷全部遷移使其回到數據庫的初始狀態，而後再使用「Update-database」回到如今。比較適合使用單元測試自動完成。

9. Relax

   Learning Migrations can be a frustrating time suck. Don’t punch your monitor. Instead take a breather and relax, then come back to it. It is an investment, but when mastered it will pay dividends to your team and process.

   參考文檔：https://elegantcode.com/2012/04/12/entity-framework-migrations-tips/