關於EF的Code First的使用以及踩坑記錄

2022-11-03 14:01:07

1. Entity Framework的簡介

Entity Framework是一種資料庫的持久化框架，是微軟開發的基於ADO.NET的ORM(Object Relational Mapping，物件關係對映)框架

它嚴格來說是由三種程式設計方式：

第一種是 "DB First",指的是資料庫優先，根據資料庫取對映實體
第二種是“Model First”指的是模型優先，根據模型取生成資料庫中的表,
第三種是“Code First”指的是程式碼優先，根據程式碼去生成資料庫中的表，還有另外一種是來自資料庫的“Code First”

2.Code First的使用

按照下面的操作安裝EF的最新版本

然後輸入“install-package entityframework” 命令

安裝成功後，開始寫程式碼

首先我們先新建幾個實體類“Student”和“SysClass”，一個學生類一個班級類，因為class

在.net中是保留字，所以我們為班級類起名“SysClass”,但是“Class”在資料庫中不是保留字多以我們可以怎樣做在“SysClass”類上打上特性**[Table(“Class”)]**，然後在其他欄位上新增幾個必要的屬性，“SysClass”的Students屬性上有個virtual，指明這個是外來鍵。

然後再新建一個“AccountContext”類這個類，繼承自"DBContext"(System.Data.Entity) 這個類封裝了對資料庫的一些設定和釋放，當然CRUD(增刪改查)也可以通過這個類來實現。

實現父類別的建構函式，傳入的引數是nameof(AccountContext)，指明的是使用哪個的資料庫的連線串，OnModelCreating()這個方法可以重寫也可以不重寫，這個方法主要是為了指明是否需要在將程式碼對映到資料庫時，是否生成複數的表名，預設情況下是自動生成複數的表名。

然後在新建一個“AccountInitialzer”類，用來初始化資料庫的，他繼承自“DropCreateDatabaseIfModelChanges”，表明是當實體改變時，刪除資料庫中的表，然後在根據程式碼對映的實體新建資料庫中的表，然後重寫它的Seed方法，

這個方法是當資料庫初始化的時候，插入一些測試的資料，它還有可以繼承DropCreateDatabaseAlways，但是這種方法比較狠，每次都會從刪除資料庫中的表，在根據程式碼去重新生成資料庫，不介意使用，需要注意的是Seek這個方法，不是執行程式都會執行的，他只在第一次建立資料庫會被執行，或者當資料庫中的表和程式碼對映的實體不一致時，他也會執行。

最後我們開始設定資料庫的連線串 name 指的是資料庫連線串的名字也是我們“AccountContext”的類傳入的引數， initial catalog 是建立的資料庫的名字，我們這裡不指明建立的資料庫的位置，當然也可以指明建立的資料庫位置，不指明的他會在你資料庫的資料夾中建立新的資料庫，還有就是 providerName=“System.Data.SqlClient” 這個一定要帶上，否則可能會出錯。

然後我們在指明我們需要使用的AccountContext 和AccountInitialzer ,向程式指明我們新建建立資料庫時，需要使用的類。

注意type裡面設定的是程式集的名稱，而不是名稱空間的名稱，還有就是disableDatabaseInitialization這個引數，false是指明啟用這個設定，true這是禁用。

然後我們在控制檯繼續敲程式碼，這裡的Using語法，說明一下我們對DBcontext這個類檢視定義發現，這個類是實現了IDisposable介面，這就意味著，它是可以被釋放的託管資源，避免記憶體越佔越多，造成的程式效能的較低，同時這也是一個好的程式設計習慣。

執行程式後，我們發現程式執行正常

我們在檢查一下資料庫，win+r 輸入命令 ssms 開啟資料庫發現，資料庫也被正常建立了，這裡說明一下，這裡除了生成了我們需要的表以外，還生成了表“dbo__MigrationHistory”,這個表是記錄資料庫遷移使用的，以後再做說明，每次資料庫表結構的更新，都會在這裡存下資料。

這樣我們的Code First就完成了。

3.EF的一些坑

看了上面的文章是不是覺得CodeFirst還是很簡單的，通過是用EF 我們甚至不再需要學習資料庫的一些知識，甚至可以讓我們不再關心資料庫內部的實現，只需要我們修改程式碼，便可以修改掉資料庫中的表結構，Code First用的好，我們甚至都不必去開啟一次資料庫。

但是EF看著好用，其實它內部的坑或者或一些比較讓人忽略的東西還是有不少的。

我們重新改造一下控制檯的程式碼，新增 context.Database.Log +=c=> Console.WriteLine©; 這句話會幫我們記錄資料的紀錄檔。

我們執行查詢操作發現控制檯多了許多程式碼，這就是資料庫的紀錄檔，當然，我們看到的這條sql語句，就是我們執行 var student = context.Student.Find(1); 這句話時，生成的sql語句，是不是用起來很方便，但是我們只需要查詢主鍵是1的資料，他卻給我們生成了這麼長的一條sql語句，是不是看起來感覺EF其實也笨笨的，所以這就是EF不適合大型專案的原因。

EF的快取機制

我們輸入這樣的程式碼，兩次查詢主鍵是1的學生

我們檢視紀錄檔，發現只生成了一條sql。

我們再次修改程式碼，我們都只是查詢主鍵是1的學生，只不過是換了一種方式，我們在檢視紀錄檔。

這裡我們發現，它生成了兩條相同的sql

這裡我們發現，find會優先去快取中去查詢資料，而where則會每次都會生成新的sql去執行查詢，就算查詢條件相同，where也會生成新的sql。所以where可以保證我們每次都能取到最新的資料，而find則不行，之所以出現這種情況，我是這麼理解的，find查詢的資料的每次都只能返回一條，資料量小，不會佔用太多的記憶體，但是where我們發現返回的是IQueryable型別的資料，這樣就不能保證返回的資料量小了，因此為了效能的這個就不會放到快取中去了。