目錄

• 1. Entity Framework的簡(jiǎn)介
• 2.Code First的使用
• 3.EF的一些坑
• EF的緩存機(jī)制
• Attach的使用
• 按需修改
• AsNoTracking的使用

最近公司需要使用EF（Entity Framework）的CodeFirst，雖然之前接觸過(guò)EF的使用,但是卻從來(lái)沒(méi)有使用過(guò)CodeFirst，所以便從網(wǎng)上和其他地方學(xué)習(xí)了一下，所以在此記錄一下， 以便以后忘記的時(shí)候，可以回顧一下。

1. Entity Framework的簡(jiǎn)介

Entity Framework是一種數(shù)據(jù)庫(kù)的持久化框架，是微軟開(kāi)發(fā)的基于ADO.NET的ORM(Object Relational Mapping，對(duì)象關(guān)系映射)框架

它嚴(yán)格來(lái)說(shuō)是由三種編程方式：

• 第一種是 "DB First",指的是數(shù)據(jù)庫(kù)優(yōu)先，根據(jù)數(shù)據(jù)庫(kù)取映射實(shí)體
• 第二種是“Model First”指的是模型優(yōu)先，根據(jù)模型取生成數(shù)據(jù)庫(kù)中的表,
• 第三種是“Code First”指的是代碼優(yōu)先，根據(jù)代碼去生成數(shù)據(jù)庫(kù)中的表，還有另外一種是來(lái)自數(shù)據(jù)庫(kù)的“Code First”

2.Code First的使用

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

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

安裝成功后，開(kāi)始寫(xiě)代碼

首先我們先新建幾個(gè)實(shí)體類“Student”和“SysClass”，一個(gè)學(xué)生類一個(gè)班級(jí)類，因?yàn)閏lass

在.net中是保留字，所以我們?yōu)榘嗉?jí)類起名“SysClass”,但是“Class”在數(shù)據(jù)庫(kù)中不是保留字多以我們可以怎樣做在“SysClass”類上打上特性**[Table(“Class”)]**，然后在其他字段上添加幾個(gè)必要的屬性，“SysClass”的Students屬性上有個(gè)virtual，指明這個(gè)是外鍵。

然后再新建一個(gè)“AccountContext”類這個(gè)類，繼承自"DBContext"(System.Data.Entity) 這個(gè)類封裝了對(duì)數(shù)據(jù)庫(kù)的一些配置和釋放，當(dāng)然CRUD(增刪改查)也可以通過(guò)這個(gè)類來(lái)實(shí)現(xiàn)。

實(shí)現(xiàn)父類的構(gòu)造函數(shù)，傳入的參數(shù)是nameof(AccountContext)，指明的是使用哪個(gè)的數(shù)據(jù)庫(kù)的連接串，OnModelCreating()這個(gè)方法可以重寫(xiě)也可以不重寫(xiě)，這個(gè)方法主要是為了指明是否需要在將代碼映射到數(shù)據(jù)庫(kù)時(shí)，是否生成復(fù)數(shù)的表名，默認(rèn)情況下是自動(dòng)生成復(fù)數(shù)的表名。

然后在新建一個(gè)“AccountInitialzer”類，用來(lái)初始化數(shù)據(jù)庫(kù)的，他繼承自“DropCreateDatabaseIfModelChanges”，表明是當(dāng)實(shí)體改變時(shí)，刪除數(shù)據(jù)庫(kù)中的表，然后在根據(jù)代碼映射的實(shí)體新建數(shù)據(jù)庫(kù)中的表，然后重寫(xiě)它的Seed方法，

這個(gè)方法是當(dāng)數(shù)據(jù)庫(kù)初始化的時(shí)候，插入一些測(cè)試的數(shù)據(jù)，它還有可以繼承DropCreateDatabaseAlways，但是這種方法比較狠，每次都會(huì)從刪除數(shù)據(jù)庫(kù)中的表，在根據(jù)代碼去重新生成數(shù)據(jù)庫(kù)，不介意使用，需要注意的是Seek這個(gè)方法，不是運(yùn)行程序都會(huì)執(zhí)行的，他只在第一次創(chuàng)建數(shù)據(jù)庫(kù)會(huì)被執(zhí)行，或者當(dāng)數(shù)據(jù)庫(kù)中的表和代碼映射的實(shí)體不一致時(shí)，他也會(huì)執(zhí)行。

最后我們開(kāi)始配置數(shù)據(jù)庫(kù)的連接串 name 指的是數(shù)據(jù)庫(kù)連接串的名字 也是我們“AccountContext”的類傳入的參數(shù)， initial catalog 是創(chuàng)建的數(shù)據(jù)庫(kù)的名字，我們這里不指明創(chuàng)建的數(shù)據(jù)庫(kù)的位置，當(dāng)然也可以指明創(chuàng)建的數(shù)據(jù)庫(kù)位置，不指明的他會(huì)在你數(shù)據(jù)庫(kù)的文件夾中創(chuàng)建新的數(shù)據(jù)庫(kù)，還有就是 providerName=“System.Data.SqlClient” 這個(gè)一定要帶上，否則可能會(huì)出錯(cuò)。

然后我們?cè)谥该魑覀冃枰褂玫腁ccountContext 和AccountInitialzer ,向程序指明我們新建創(chuàng)建數(shù)據(jù)庫(kù)時(shí)，需要使用的類。

注意type里面配置的是程序集的名稱，而不是命名空間的名稱，還有就是disableDatabaseInitialization這個(gè)參數(shù)，false是指明啟用這個(gè)配置，true這是禁用。

然后我們?cè)诳刂婆_(tái)繼續(xù)敲代碼，這里的Using語(yǔ)法，說(shuō)明一下我們對(duì)DBcontext這個(gè)類查看定義發(fā)現(xiàn)，這個(gè)類是實(shí)現(xiàn)了IDisposable接口，這就意味著，它是可以被釋放的托管資源，避免內(nèi)存越占越多，造成的程序性能的較低，同時(shí)這也是一個(gè)好的編程習(xí)慣。

運(yùn)行程序后，我們發(fā)現(xiàn)程序運(yùn)行正常

我們?cè)跈z查一下數(shù)據(jù)庫(kù)，win+r 輸入命令 ssms 打開(kāi)數(shù)據(jù)庫(kù)發(fā)現(xiàn)，數(shù)據(jù)庫(kù)也被正常創(chuàng)建了，這里說(shuō)明一下，這里除了生成了我們需要的表以外，還生成了表“dbo__MigrationHistory”,這個(gè)表是記錄數(shù)據(jù)庫(kù)遷移使用的，以后再做說(shuō)明，每次數(shù)據(jù)庫(kù)表結(jié)構(gòu)的更新，都會(huì)在這里存下數(shù)據(jù)。

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

3.EF的一些坑

看了上面的文章是不是覺(jué)得CodeFirst還是很簡(jiǎn)單的，通過(guò)是用EF 我們甚至不再需要學(xué)習(xí)數(shù)據(jù)庫(kù)的一些知識(shí)，甚至可以讓我們不再關(guān)心數(shù)據(jù)庫(kù)內(nèi)部的實(shí)現(xiàn)，只需要我們修改代碼，便可以修改掉數(shù)據(jù)庫(kù)中的表結(jié)構(gòu)，Code First用的好，我們甚至都不必去打開(kāi)一次數(shù)據(jù)庫(kù)。

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

我們重新改造一下控制臺(tái)的代碼，添加 context.Database.Log +=c=> Console.WriteLine©; 這句話會(huì)幫我們記錄數(shù)據(jù)的日志。

我們執(zhí)行查詢操作 發(fā)現(xiàn)控制臺(tái)多了許多代碼，這就是數(shù)據(jù)庫(kù)的日志，當(dāng)然，我們看到的這條sql語(yǔ)句，就是我們執(zhí)行 var student = context.Student.Find(1); 這句話時(shí)，生成的sql語(yǔ)句，是不是用起來(lái)很方便，但是我們只需要查詢主鍵是1的數(shù)據(jù)，他卻給我們生成了這么長(zhǎng)的一條sql語(yǔ)句，是不是看起來(lái)感覺(jué)EF其實(shí)也笨笨的，所以這就是EF不適合大型項(xiàng)目的原因。

EF的緩存機(jī)制

我們輸入這樣的代碼，兩次查詢主鍵是1的學(xué)生

我們查看日志，發(fā)現(xiàn)只生成了一條sql。

我們?cè)俅涡薷拇a，我們都只是查詢主鍵是1的學(xué)生，只不過(guò)是換了一種方式，我們?cè)诓榭慈罩尽?/p>

這里我們發(fā)現(xiàn)，它生成了兩條相同的sql

這里我們發(fā)現(xiàn)，find會(huì)優(yōu)先去緩存中去查詢數(shù)據(jù)，而where則會(huì)每次都會(huì)生成新的sql去執(zhí)行查詢，就算查詢條件相同，where也會(huì)生成新的sql。所以where可以保證我們每次都能取到最新的數(shù)據(jù)，而find則不行，之所以出現(xiàn)這種情況，我是這么理解的，find查詢的數(shù)據(jù)的每次都只能返回一條，數(shù)據(jù)量小，不會(huì)占用太多的內(nèi)存，但是where我們發(fā)現(xiàn)返回的是IQueryable類型的數(shù)據(jù)，這樣就不能保證返回的數(shù)據(jù)量小了，因此為了性能的這個(gè)就不會(huì)放到緩存中去了。

Attach的使用

我們修改一下代碼：

我們先查詢一個(gè)學(xué)生，然后在修改它的Name屬性，然后保存，這里result返回的是0，意思是沒(méi)有執(zhí)行成功，我們查看數(shù)據(jù)庫(kù)發(fā)現(xiàn)確實(shí)沒(méi)有修改成功。

這里就要說(shuō)明一下了，這里我們使用的是兩個(gè)AccountContext對(duì)象，context對(duì)象查詢出了學(xué)生student，context對(duì)象便開(kāi)始監(jiān)管這個(gè)對(duì)象，我們用context1這個(gè)對(duì)象修改是，因?yàn)閏ontext1這個(gè)對(duì)象，根本就不知道student是誰(shuí)，當(dāng)然會(huì)修改失敗了。

這樣我們?cè)谛薷囊幌麓a：

我們發(fā)現(xiàn)返回的是1，當(dāng)在查看數(shù)據(jù)庫(kù)時(shí)，發(fā)現(xiàn)數(shù)據(jù)庫(kù)的信息被修改了。

Attach是將查出來(lái)的student讓context1進(jìn)行監(jiān)管，就相當(dāng)于與這個(gè)student對(duì)象是被context1查出來(lái)的一樣，但也是有區(qū)別的，所以我們就修改成功了。

需要注意的是如果被修改的對(duì)象的屬性在Attach之前，會(huì)修改失敗的，因?yàn)槟菚r(shí)候，context1還沒(méi)有對(duì)student進(jìn)行監(jiān)管。

比如這樣，就會(huì)修改失敗,

按需修改

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

查看日志，發(fā)現(xiàn)只修改了Name屬性，

AsNoTracking的使用

我們?cè)俅涡薷拇a

我們?cè)诓樵兊降臄?shù)據(jù)中添加AsNoTracking（）的方法，再次修改實(shí)體，發(fā)現(xiàn)修改失敗了，這里解釋一下AsNoTracking（）這個(gè)方法，他表示不再追蹤這條數(shù)據(jù)，也就是context這個(gè)對(duì)象不再監(jiān)管oldstudent這個(gè)對(duì)象，所以會(huì)修改失敗的，雖然一定程度上可以提高性能，但是介意不要使用。

好了，本篇文章就到此為止了。以后再介紹EF的其他知識(shí)點(diǎn)。以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持。