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

Posted on by

最近公司需要使用EF（Entity Framework）的CodeFirst，雖然之前接觸過EF的使用,但是卻從來沒有使用過CodeFirst，所以便從網上和其他地方學習瞭一下，所以在此記錄一下， 以便以後忘記的時候，可以回顧一下。

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類型的數據，這樣就不能保證返回的數據量小瞭，因此為瞭性能的這個就不會放到緩存中去瞭。 

Attach的使用

我們修改一下代碼：

我們先查詢一個學生，然後在修改它的Name屬性，然後保存，這裡result返回的是0，意思是沒有執行成功，我們查看數據庫發現確實沒有修改成功。

這裡就要說明一下瞭，這裡我們使用的是兩個AccountContext對象，context對象查詢出瞭學生student，context對象便開始監管這個對象，我們用context1這個對象修改是，因為context1這個對象，根本就不知道student是誰，當然會修改失敗瞭。

這樣我們在修改一下代碼：

我們發現返回的是1，當在查看數據庫時，發現數據庫的信息被修改瞭。

Attach是將查出來的student讓context1進行監管，就相當於與這個student對象是被context1查出來的一樣，但也是有區別的，所以我們就修改成功瞭。

需要註意的是如果被修改的對象的屬性在Attach之前，會修改失敗的，因為那時候，context1還沒有對student進行監管。

比如這樣，就會修改失敗,

按需修改

EF是支持按需修改的，我們修改代碼：

查看日志，發現隻修改瞭Name屬性，

AsNoTracking的使用

我們再次修改代碼

我們在查詢到的數據中添加AsNoTracking（）的方法，再次修改實體，發現修改失敗瞭，這裡解釋一下AsNoTracking（）這個方法，他表示不再追蹤這條數據，也就是context這個對象不再監管oldstudent這個對象，所以會修改失敗的，雖然一定程度上可以提高性能，但是介意不要使用。

好瞭，本篇文章就到此為止瞭。以後再介紹EF的其他知識點。以上為個人經驗，希望能給大傢一個參考，也希望大傢多多支持WalkonNet。

推薦閱讀：