1. 動(dòng)手之前先想清楚EF框架的版本與項(xiàng)目匹配問(wèn)題1.1 同樣是EFEF6和EF Core是兩套東西第一次在Visual Studio里接觸EF框架的人打開(kāi)NuGet包管理器時(shí)大概率會(huì)愣一下搜EntityFramework出來(lái)一大排EntityFramework 6.x、Microsoft.EntityFrameworkCore、Microsoft.EntityFrameworkCore.SqlServer到底裝哪個(gè)我在各種項(xiàng)目里來(lái)回切換過(guò)結(jié)論其實(shí)很直接如果項(xiàng)目是.NET Framework體系常見(jiàn)于傳統(tǒng)WinForms、WPF、老Web項(xiàng)目、很多工控上位機(jī)老老實(shí)實(shí)用EF6如果項(xiàng)目是.NET Core或.NET 5以上的現(xiàn)代體系用EF Core。這兩者的區(qū)別不只是版本號(hào)整個(gè)底層設(shè)計(jì)都換了。EF6是.NET Framework時(shí)代成長(zhǎng)起來(lái)的重量級(jí)ORM功能高度集成配置文件多對(duì)老項(xiàng)目支持好尤其是像WinForms上位機(jī)這類需要快速對(duì)接本地?cái)?shù)據(jù)庫(kù)、內(nèi)網(wǎng)部署的場(chǎng)景EF6非常穩(wěn)。EF Core是微軟后來(lái)針對(duì)跨平臺(tái)和現(xiàn)代架構(gòu)重寫(xiě)的產(chǎn)物模塊化、體積輕、支持依賴注入、原生異步性能也優(yōu)化了不少EF Core 8/9已經(jīng)做到了很多以前EF6做不到的事。判斷方式極簡(jiǎn)單在Visual Studio里新建項(xiàng)目時(shí)目標(biāo)框架那欄如果是.NET 6/7/8/9就選EF Core如果是.NET Framework 4.6.1/4.7.2/4.8選EF6。用錯(cuò)版本最典型的后果是你明明在EF Core項(xiàng)目里裝了EF6的包運(yùn)行時(shí)報(bào)一堆奇怪的程序集加載失敗。這不是代碼問(wèn)題是選型問(wèn)題越早理解越省事。1.2 Visual Studio版本與EF框架的兼容關(guān)系Visual Studio本身只是個(gè)IDE它對(duì)EF框架的使用影響主要在兩點(diǎn)一是新建項(xiàng)目時(shí)決定你能選什么目標(biāo)框架二是NuGet包管理器幫你拉依賴。VS2019、VS2022、VS2026這些版本對(duì)EF6和EF Core都能正常支持沒(méi)有說(shuō)哪個(gè)VS版本必須配哪個(gè)EF版本。真正會(huì)產(chǎn)生影響的是你的項(xiàng)目目標(biāo)框架。比如EF Core 8官方要求net8.0如果你的VS里裝的是老版.NET SDK新建項(xiàng)目時(shí)只能選net6.0那強(qiáng)行裝EF Core 8包就會(huì)報(bào)NU1202不兼容的包依賴。解決方案也直接要么降低EF Core版本比如裝6.x或7.x要么升級(jí)項(xiàng)目目標(biāo)框架到net8.0。我個(gè)人的建議是新機(jī)器新項(xiàng)目直接上VS2022以上的版本并安裝標(biāo)準(zhǔn)的工作負(fù)載。在Visual Studio Installer里勾選ASP.NET和Web開(kāi)發(fā)和.NET桌面開(kāi)發(fā)前者覆蓋Web API、MVC項(xiàng)目后者覆蓋WinForms、WPF上位機(jī)項(xiàng)目。安裝完成后在項(xiàng)目屬性里確認(rèn)目標(biāo)框架保證和要用的EF版本匹配后面基本不會(huì)在環(huán)境層面出幺蛾子。2. 從建項(xiàng)目到裝好EF包NuGet環(huán)節(jié)的幾個(gè)關(guān)鍵細(xì)節(jié)2.1 項(xiàng)目骨架怎么搭最省心很多初學(xué)者一上來(lái)就想著分層架構(gòu)、倉(cāng)儲(chǔ)模式、依賴注入其實(shí)在Visual Studio里第一步嘗試EF建一個(gè)簡(jiǎn)單的控制臺(tái)項(xiàng)目或ASP.NET Core Web API項(xiàng)目就夠用了。控制臺(tái)項(xiàng)目方便你打斷點(diǎn)調(diào)試Web API項(xiàng)目更容易模擬真實(shí)場(chǎng)景。我個(gè)人推薦第一次練手用ASP.NET Core Web API加EF Core因?yàn)楹罄m(xù)寫(xiě)接口、注入DbContext都順路。創(chuàng)建項(xiàng)目時(shí)注意命名空間規(guī)范比如解決方案名EFDemo項(xiàng)目名EFDemo.Api。類庫(kù)要不要單獨(dú)拆出來(lái)初期不用拆把實(shí)體類和DbContext直接放在主項(xiàng)目下等運(yùn)行通了一個(gè)完整CRUD流程再考慮拆分。為什么因?yàn)镋F框架的調(diào)試難度主要集中在數(shù)據(jù)庫(kù)連接和模型映射上項(xiàng)目結(jié)構(gòu)越簡(jiǎn)單你越容易定位問(wèn)題。2.2 NuGet安裝EF6和EF Core各自的正確姿勢(shì)在Visual Studio里裝EF包有兩條路一條是圖形界面右鍵項(xiàng)目選管理NuGet程序包瀏覽頁(yè)搜索包名選對(duì)應(yīng)版本安裝另一條是包管理器控制臺(tái)工具- NuGet包管理器 - 程序包管理器控制臺(tái)輸命令。EF6只需要一個(gè)包Install-Package EntityFramework這個(gè)包會(huì)把EF6的運(yùn)行時(shí)、設(shè)計(jì)時(shí)工具全部帶上不用再裝別的。如果你用的是SQL Server家族數(shù)據(jù)庫(kù)這個(gè)包就夠。EF Core則稍有講究通常不需要單獨(dú)裝Microsoft.EntityFrameworkCore而是直接裝對(duì)應(yīng)的數(shù)據(jù)庫(kù)提供程序包它會(huì)通過(guò)依賴把核心包帶進(jìn)來(lái)Install-Package Microsoft.EntityFrameworkCore.SqlServer如果你用的是SQLite、PostgreSQL、MySQL則分別裝Microsoft.EntityFrameworkCore.Sqlite、Npgsql.EntityFrameworkCore.PostgreSQL、Pomelo.EntityFrameworkCore.MySql。很多人裝了主包忘了提供程序包結(jié)果運(yùn)行時(shí)報(bào)沒(méi)有找到數(shù)據(jù)庫(kù)提供程序的錯(cuò)誤根源就在這里。EF Core的設(shè)計(jì)哲學(xué)就是你用哪個(gè)庫(kù)就裝哪個(gè)包其余的都當(dāng)傳遞依賴自動(dòng)處理。2.3 安裝中常年見(jiàn)到的三類異常第一類是版本沖突。表現(xiàn)是安裝進(jìn)度條走了半天最后報(bào)NU1107或NU1608之類依賴沖突錯(cuò)誤。處理思路不是瞎試版本而是看項(xiàng)目目標(biāo)框架和包版本是否匹配比如net6.0項(xiàng)目強(qiáng)行裝EF Core 8就是典型沖突這種情況要么升目標(biāo)框架要么降EF版本到6.0.x。第二類是下載卡在0B或進(jìn)度條一直不動(dòng)。這在Visual Studio里相當(dāng)常見(jiàn)原因是NuGet默認(rèn)源訪問(wèn)慢或網(wǎng)絡(luò)被限制。處理方法是在NuGet包管理器右上角的源設(shè)置里把包源切換到國(guó)內(nèi)可用的鏡像源。第三類是Packages.config和PackageReference混用造成的重復(fù)引用。老項(xiàng)目用packages.config新項(xiàng)目用PackageReference如果同一個(gè)項(xiàng)目里兩種引用方式都存在編譯時(shí)會(huì)看到大量重復(fù)引用警告甚至導(dǎo)致程序集版本錯(cuò)亂。建議在項(xiàng)目文件里把packages.config刪掉統(tǒng)一改成PackageReference或者通過(guò)VS的遷移功能一鍵轉(zhuǎn)換。3. Code First建模從實(shí)體類到數(shù)據(jù)庫(kù)誕生的完整鏈路3.1 實(shí)體類定義別只寫(xiě)屬性主鍵和外鍵約定要看懂EF框架的三種建模方式——Code First、Database First、Model First——我強(qiáng)烈建議新項(xiàng)目用Code First也就是先寫(xiě)C#類再由EF幫你創(chuàng)建數(shù)據(jù)庫(kù)表。這種方式的可讀性和維護(hù)性都是最好的代碼即模型配合遷移機(jī)制數(shù)據(jù)庫(kù)結(jié)構(gòu)的演進(jìn)就是代碼變更的歷史記錄。下面是一個(gè)典型的訂單場(chǎng)景包含商品和分類兩個(gè)表外加訂單明細(xì)public class Category { public int Id { get; set; } public string Name { get; set; } string.Empty; public ICollectionProduct Products { get; set; } new ListProduct(); } public class Product { public int Id { get; set; } public string Name { get; set; } string.Empty; public decimal Price { get; set; } public int CategoryId { get; set; } public Category? Category { get; set; } }這里有幾個(gè)約定值得解釋。主鍵屬性取名Id或以類名Id結(jié)尾比如CategoryIdEF會(huì)自動(dòng)識(shí)別為主鍵不需要額外標(biāo)注。外鍵Product里的CategoryId會(huì)被識(shí)別為外鍵同時(shí)定義了一個(gè)Category導(dǎo)航屬性EF就能自動(dòng)建立兩個(gè)表的關(guān)系。字符串類型默認(rèn)映射為nvarchar(max)這在實(shí)際項(xiàng)目里通常不夠嚴(yán)謹(jǐn)需要用Data Annotation特性或Fluent API限定長(zhǎng)度。public class Product { public int Id { get; set; } [MaxLength(100)] public string Name { get; set; } string.Empty; [Column(TypeName decimal(18,2))] public decimal Price { get; set; } }3.2 DbContextEF框架的交通樞紐DbContext是EF框架的使用核心。它負(fù)責(zé)管理實(shí)體對(duì)象、查詢數(shù)據(jù)庫(kù)、保存變更有點(diǎn)像數(shù)據(jù)庫(kù)連接和實(shí)體集合之間的總調(diào)度室。一個(gè)簡(jiǎn)潔的DbContext這樣寫(xiě)public class AppDbContext : DbContext { public AppDbContext(DbContextOptionsAppDbContext options) : base(options) { } public DbSetProduct Products SetProduct(); public DbSetCategory Categories SetCategory(); protected override void OnModelCreating(ModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); modelBuilder.EntityProduct(entity { entity.Property(p p.Price).HasPrecision(18, 2); entity.HasOne(p p.Category) .WithMany(c c.Products) .HasForeignKey(p p.CategoryId); }); } }我建議表結(jié)構(gòu)復(fù)雜時(shí)優(yōu)先使用Fluent API就是OnModelCreating里的寫(xiě)法因?yàn)镈ata Annotation把規(guī)則散落在各個(gè)實(shí)體屬性上表關(guān)系一多看起來(lái)非常亂而Fluent API集中管理別人接手時(shí)一眼能看到所有映射規(guī)則。下面這幾種配置在真實(shí)項(xiàng)目中出現(xiàn)頻率極高限制字符串長(zhǎng)度、設(shè)置decimal精度、建立唯一索引。modelBuilder.EntityProduct(entity { entity.HasIndex(p p.Name).IsUnique(); });3.3 連接字符串的兩種配置位置連接字符串告訴EF去哪里找數(shù)據(jù)庫(kù)。EF6通常寫(xiě)在App.config或Web.config的 節(jié)connectionStrings add nameAppDbContext connectionStringServer.;DatabaseEFDemoDb;Trusted_ConnectionTrue;TrustServerCertificateTrue; providerNameSystem.Data.SqlClient / /connectionStringsEF Core則寫(xiě)appsettings.json{ ConnectionStrings: { DefaultConnection: Server.;DatabaseEFDemoDb;Trusted_ConnectionTrue;TrustServerCertificateTrue; } }注意EF6的配置里多了providerNameSystem.Data.SqlClient而EF Core不需要。很多人在EF Core項(xiàng)目里照抄EF6的配置結(jié)果報(bào)關(guān)鍵字不受支持的錯(cuò)就是這個(gè)原因。另外本地開(kāi)發(fā)建議用默認(rèn)實(shí)例加Windows身份驗(yàn)證真到部署環(huán)境再切換成SQL賬號(hào)連接串。3.4 數(shù)據(jù)庫(kù)生成執(zhí)行遷移命令的那幾步寫(xiě)好實(shí)體和DbContext后要讓Visual Studio幫我們生成數(shù)據(jù)庫(kù)步驟如下首先在包管理器控制臺(tái)里把默認(rèn)項(xiàng)目選成DbContext所在的項(xiàng)目。然后輸入Enable-MigrationsEF6的舊命令EF Core則不用這一步直接從Add-Migration開(kāi)始。依次執(zhí)行Add-Migration Init Update-Database -VerboseAdd-Migration會(huì)掃描模型變化并生成一個(gè)遷移類里面寫(xiě)了Up和Down方法Update-Database把遷移應(yīng)用到數(shù)據(jù)庫(kù)-Verbose可以打印實(shí)際執(zhí)行的SQL我強(qiáng)烈建議帶上這個(gè)參數(shù)能直觀看到EF是怎么建表的。如果數(shù)據(jù)庫(kù)不存在EF會(huì)自行創(chuàng)建。第一次跑通這套流程后你會(huì)發(fā)現(xiàn)自己建庫(kù)的速度比在SSMS里手寫(xiě)SQL快得多。而且因?yàn)橛辛诉w移腳本后續(xù)無(wú)論換機(jī)器還是換同事一條Update-Database就能把庫(kù)結(jié)構(gòu)還原出來(lái)。4. 日常CRUD之外DbContext真正值得花時(shí)間研究的幾個(gè)點(diǎn)4.1 SaveChanges是分水嶺增刪改都要靠它落庫(kù)EF框架的增刪改查看著簡(jiǎn)單實(shí)際用起來(lái)有幾個(gè)重要的心理預(yù)期。先說(shuō)增刪改一個(gè)完整的插入流程如下using var db new AppDbContext(GetOptions()); var category new Category { Name 飲料 }; db.Categories.Add(category); await db.SaveChangesAsync();關(guān)鍵在于后面這行SaveChangesAsync。Add方法只是把實(shí)體標(biāo)記為Added狀態(tài)對(duì)象圖還停留在內(nèi)存里只有調(diào)了SaveChangesEF才會(huì)真正生成INSERT語(yǔ)句發(fā)往數(shù)據(jù)庫(kù)。即使你Add了十個(gè)、一百個(gè)實(shí)體都是同一行SaveChanges統(tǒng)一提交。刪除和更新也是同一個(gè)套路先查出實(shí)體要么Remove標(biāo)記刪除要么改屬性等SaveChanges統(tǒng)一Update。var product await db.Products.FindAsync(id); if (product ! null) { product.Price 9.9m; await db.SaveChangesAsync(); }很多新手在這里犯迷糊改完屬性以為立刻生效切到數(shù)據(jù)庫(kù)一看沒(méi)變化來(lái)來(lái)回回排查半天其實(shí)只是少了一句SaveChanges。4.2 IQueryable的延遲執(zhí)行原來(lái)查詢并沒(méi)有真的查詢EF框架的查詢有個(gè)反直覺(jué)的地方。你用db.Products.Where(p p.Price 10)并不會(huì)立刻執(zhí)行SQL它只是構(gòu)建了一個(gè)IQueryable表達(dá)式樹(shù)。真正打開(kāi)數(shù)據(jù)庫(kù)連接、跑SQL的地方是遍歷結(jié)果的那一刻比如ToListAsync、FirstOrDefaultAsync。這個(gè)特性帶來(lái)的好處是你可以在分頁(yè)、過(guò)濾條件不確定的場(chǎng)景下逐步疊加查詢條件最后再一次性執(zhí)行。但副作用也明顯如果你在循環(huán)里遍歷某個(gè)IQueryable結(jié)果每遍歷一次就執(zhí)行一次SQL性能立馬崩盤(pán)。導(dǎo)航屬性也有類似陷阱。只查詢Product列表時(shí)Category是空的因?yàn)镋F默認(rèn)不加載關(guān)聯(lián)對(duì)象。要一次性把關(guān)聯(lián)數(shù)據(jù)取出來(lái)用Includevar products await db.Products .Include(p p.Category) .Where(p p.CategoryId 1) .ToListAsync();這樣生成的SQL會(huì)帶JOIN一次取回關(guān)聯(lián)數(shù)據(jù)。如果不加Include循環(huán)里又訪問(wèn)p.Category.Name就會(huì)造成所謂的N1查詢問(wèn)題——主表查一次每個(gè)子對(duì)象再查一次數(shù)據(jù)量大時(shí)性能極其難看。判斷這個(gè)問(wèn)題的辦法很簡(jiǎn)單把EF生成的SQL打印出來(lái)看LOG里的SELECT條數(shù)幾條就是幾個(gè)查詢。4.3 只讀場(chǎng)景加AsNoTracking批量插入關(guān)掉自動(dòng)檢測(cè)EF框架默認(rèn)會(huì)跟蹤查詢出來(lái)的每一個(gè)實(shí)體。這意味著當(dāng)你查詢1萬(wàn)條數(shù)據(jù)時(shí)DbContext內(nèi)部的狀態(tài)管理器就咬著這1萬(wàn)條實(shí)體的快照不放內(nèi)存占用和變更檢測(cè)的開(kāi)銷都不小。對(duì)于純展示、不修改數(shù)據(jù)的查詢加一個(gè)AsNoTracking就能繞開(kāi)跟蹤機(jī)制var categories await db.Categories .AsNoTracking() .ToListAsync();注意用了AsNoTracking之后查詢出來(lái)的實(shí)體就脫離DbContext管理了對(duì)它做修改再SaveChanges是無(wú)效的。所以這個(gè)優(yōu)化只對(duì)只讀場(chǎng)景使用。批量插入的另一個(gè)隱藏性能殺手是AutoDetectChangesEnabled。EF每次SaveChanges之前都會(huì)自動(dòng)探測(cè)所有實(shí)體有沒(méi)有變化如果你的循環(huán)里逐條Add實(shí)際開(kāi)銷會(huì)隨實(shí)體數(shù)量指數(shù)級(jí)上升。大量導(dǎo)入時(shí)先關(guān)掉檢測(cè)db.ChangeTracker.AutoDetectChangesEnabled false; for (int i 0; i 10000; i) { db.Products.Add(new Product { Name 商品 i }); } await db.SaveChangesAsync(); db.ChangeTracker.AutoDetectChangesEnabled true;真實(shí)項(xiàng)目中我見(jiàn)過(guò)有人循環(huán)Add一萬(wàn)條數(shù)據(jù)足足跑了30多秒關(guān)掉自動(dòng)檢測(cè)后壓到2秒左右效果非常明顯。4.4 事務(wù)和并發(fā)不是高端技巧是保命技能多個(gè)表要么同時(shí)成功要么同時(shí)失敗這種場(chǎng)景必須用事務(wù)。EF6里用Database.BeginTransactionEF Core里同樣支持await using var transaction await db.Database.BeginTransactionAsync(); try { db.Categories.Add(new Category { Name 日用 }); await db.SaveChangesAsync(); db.Products.Add(new Product { Name 紙巾, Price 3.5m }); await db.SaveChangesAsync(); await transaction.CommitAsync(); } catch { await transaction.RollbackAsync(); throw; }并發(fā)控制方面最簡(jiǎn)單可靠的方式是給表加rowversion并發(fā)字段。SQL Server里定義一列byte[]類型的Version或TimestampEF自動(dòng)將其映射為rowversion。當(dāng)兩個(gè)用戶同時(shí)修改同一條記錄時(shí)后提交的一方會(huì)拋出DbUpdateConcurrencyException你就知道這條數(shù)據(jù)被別人動(dòng)過(guò)了可以提示用戶重新加載數(shù)據(jù)。5. 數(shù)據(jù)庫(kù)結(jié)構(gòu)變更以后遷移機(jī)制的正確打開(kāi)方式5.1 別肝數(shù)據(jù)庫(kù)表遷移才是正路項(xiàng)目迭代到中期實(shí)體類必然會(huì)加字段、改長(zhǎng)度、加索引。如果你直接去SQL Server Management Studio里手改表結(jié)構(gòu)代碼倒是能跑一陣但EF框架內(nèi)部維護(hù)著一個(gè)模型快照ModelSnapshot只要你改了實(shí)體EF就知道模型和數(shù)據(jù)庫(kù)對(duì)不上運(yùn)行時(shí)直接給你拋模型已更改的異常。正確做法永遠(yuǎn)走遷移。每改一次模型執(zhí)行一次Add-Migration再Update-Database。比如給Product加一個(gè)Stock字段public int Stock { get; set; }然后Add-Migration AddStockToProduct Update-Database這樣EF會(huì)生成一個(gè)包含ALTER TABLE語(yǔ)句的遷移文件數(shù)據(jù)庫(kù)結(jié)構(gòu)就跟著代碼走了。5.2 Add-Migration生成的文件里藏著什么遷移文件分三部分Up方法寫(xiě)的是正向遷移的變更Down方法寫(xiě)的是回退。比如加了Stock字段Down方法里就會(huì)刪掉這一列。這意味著你的數(shù)據(jù)庫(kù)結(jié)構(gòu)是可以向前向后任意遷移的團(tuán)隊(duì)里任何一個(gè)人拉代碼后執(zhí)行Update-Database就能得到和開(kāi)發(fā)環(huán)境一致的數(shù)據(jù)庫(kù)結(jié)構(gòu)。不過(guò)有一點(diǎn)要注意遷移文件的順序很重要EF按時(shí)間順序應(yīng)用遷移不要隨便刪改已經(jīng)應(yīng)用過(guò)的遷移文件。如果遷移還沒(méi)上線你想改模型重新生成可以直接刪掉該遷移和數(shù)據(jù)庫(kù)里對(duì)應(yīng)的版本記錄再重來(lái)如果已經(jīng)部署到生產(chǎn)了那就只能繼續(xù)追加新遷移不能回頭改舊的這是原則。5.3 生產(chǎn)環(huán)境更新用腳本而不是直接連庫(kù)執(zhí)行生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)一般不會(huì)允許你直接從Visual Studio連上去Update-Database正規(guī)一點(diǎn)的操作是導(dǎo)出SQL腳本交給DBA審核執(zhí)行Update-Database -Script -SourceMigration Init -TargetMigration Latest這個(gè)命令會(huì)把從Init遷移到最新版本的所有SQL腳本生成出來(lái)不連接數(shù)據(jù)庫(kù)。也可以簡(jiǎn)寫(xiě)成Update-Database -Script在有遷移歷史記錄的庫(kù)上它會(huì)輸出增量變更腳本。線下系統(tǒng)我還會(huì)配合使用EnsureCreated和Migrate的區(qū)別說(shuō)明EnsureCreated適合一次性創(chuàng)建數(shù)據(jù)庫(kù)的極簡(jiǎn)場(chǎng)景比如本地demo它完全不記錄遷移歷史后面加字段也不會(huì)自動(dòng)更新而Migrate則是正式項(xiàng)目應(yīng)該使用的初始化方式它會(huì)應(yīng)用所有遷移并維護(hù)版本表。生產(chǎn)環(huán)境務(wù)必用Migrate或腳本更新而不是EnsureCreated。6. 實(shí)戰(zhàn)里我和EF框架交過(guò)手的幾個(gè)經(jīng)典問(wèn)題6.1 自數(shù)據(jù)庫(kù)創(chuàng)建后已更改這個(gè)報(bào)錯(cuò)的真相這是EF6里最著名的報(bào)錯(cuò)之一自數(shù)據(jù)庫(kù)創(chuàng)建后模型是否有更改。觸發(fā)原因基本就是數(shù)據(jù)庫(kù)表結(jié)構(gòu)和模型不一致而EF6默認(rèn)用一張EdmMetadata表記錄模型哈希值一旦哈希對(duì)不上就直接拒絕干活。解決方案不是禁用檢查而是重新走一次遷移讓模型和庫(kù)對(duì)齊。如果是在EF Core里同樣的問(wèn)題表現(xiàn)稍有不同但排查思路一致先對(duì)比實(shí)體類和數(shù)據(jù)庫(kù)表找出新增的字段或移除的列再補(bǔ)一條遷移。6.2 未能加載文件或程序集EntityFramework怎么查這類報(bào)錯(cuò)大多出現(xiàn)在EF6項(xiàng)目里項(xiàng)目能編譯但一運(yùn)行就掛。大概率是NuGet包沒(méi)裝全或者配置文件缺少entityFramework節(jié)。EF6默認(rèn)會(huì)在App.config/Web.config里寫(xiě)入這樣一段entityFramework defaultConnectionFactory typeSystem.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework / /entityFramework如果沒(méi)有這段并且你的項(xiàng)目中也沒(méi)顯式指定連接工廠運(yùn)行時(shí)就可能找不到程序集。最穩(wěn)妥的修復(fù)方式卸載EntityFramework包重新安裝讓系統(tǒng)自動(dòng)生成配置。如果是EF Core項(xiàng)目更有可能是數(shù)據(jù)庫(kù)提供程序包沒(méi)裝比如你只裝了Microsoft.EntityFrameworkCore卻用了SqlServer連接運(yùn)行時(shí)報(bào)Unable to find provider。6.3 連接字符串沒(méi)生效數(shù)據(jù)庫(kù)連到了奇怪的地方我見(jiàn)過(guò)很多次這種情況明明在appsettings.json里寫(xiě)了連到生產(chǎn)庫(kù)的字符串程序卻連到了本地LocalDB。排查思路很直接先看Program.cs里UseSqlServer是否顯式傳入了連接字符串名稱比如builder.Services.AddDbContextAppDbContext(options options.UseSqlServer(builder.Configuration.GetConnectionString(DefaultConnection)));注意CreateDbContext或Program.cs里注入時(shí)用的字符串名稱必須要和配置文件里的Key完全一致大小寫(xiě)也得對(duì)。另外EF Core在設(shè)計(jì)時(shí)遷移比如Add-Migration時(shí)會(huì)嘗試讀取連接串如果讀取不到或名稱不對(duì)它會(huì)默認(rèn)選擇一個(gè)錯(cuò)誤的數(shù)據(jù)源。最簡(jiǎn)單粗暴的驗(yàn)證方法是在DbContext的OnConfiguring里臨時(shí)寫(xiě)一個(gè)固定的連接串跑通流程確認(rèn)問(wèn)題出在配置讀取后再改回依賴注入的寫(xiě)法。6.4 導(dǎo)航屬性明明寫(xiě)了virtual懶加載還是不生效EF6里使用懶加載有兩個(gè)條件導(dǎo)航屬性必須標(biāo)記為virtual并且DbContext配置了LazyLoadingEnabled。EF Core從3.0開(kāi)始默認(rèn)就關(guān)閉了懶加載需要額外安裝Microsoft.EntityFrameworkCore.Proxies包并顯式開(kāi)啟UseLazyLoadingProxies。optionsBuilder.UseLazyLoadingProxies() .UseSqlServer(connectionString);但我的實(shí)際建議是新項(xiàng)目不要依賴懶加載。懶加載雖然在訪問(wèn)屬性時(shí)自動(dòng)加載數(shù)據(jù)很爽但實(shí)際上是在隱藏查詢行為稍不留神就產(chǎn)生N1查詢問(wèn)題。與其等坑出現(xiàn)再優(yōu)化不如從一開(kāi)始就用Include或Select顯式加載你真正需要的數(shù)據(jù)。關(guān)閉懶加載之后代碼邏輯反而清晰因?yàn)槊看螖?shù)據(jù)庫(kù)訪問(wèn)都在你能看見(jiàn)的地方。6.5 批量插入幾千條數(shù)據(jù)越插越慢除了前面提過(guò)的AutoDetectChangesEnabled執(zhí)行批量插入時(shí)還有一個(gè)隱藏開(kāi)銷每次Add后DbContext會(huì)實(shí)時(shí)計(jì)算關(guān)系修復(fù)操作逐條Add上幾千條數(shù)據(jù)這部分消耗同樣不小。除了關(guān)掉自動(dòng)檢測(cè)更徹底的辦法是改用EF Core 7及以上版本引入的ExecuteDelete和ExecuteUpdate這類批處理API。比如批量更新價(jià)格await db.Products .Where(p p.CategoryId 1) .ExecuteUpdateAsync(setters setters.SetProperty(p p.Price, 9.9m));這種操作繞過(guò)DbContext的跟蹤機(jī)制直接生成一條UPDATE語(yǔ)句發(fā)到數(shù)據(jù)庫(kù)不加載實(shí)體也不逐條SaveChanges幾十萬(wàn)條數(shù)據(jù)的更新也只要幾秒鐘。6.6 遷移歷史表不一致導(dǎo)致Update-Database失敗團(tuán)隊(duì)協(xié)作時(shí)遷移版本和數(shù)據(jù)庫(kù)里實(shí)際已應(yīng)用的版本對(duì)不上是Update-Database報(bào)錯(cuò)的高發(fā)區(qū)。檢查對(duì)策分兩步第一步在SQL Server里看__EFMigrationsHistory表里面記錄了所有已執(zhí)行的遷移ID第二步在項(xiàng)目遷移文件夾里對(duì)比遷移文件找出本地有但數(shù)據(jù)庫(kù)沒(méi)記錄的那個(gè)版本確認(rèn)是別人提交的新遷移就繼續(xù)執(zhí)行如果是自己本地生成的重復(fù)遷移就要考慮刪除或者手動(dòng)補(bǔ)一條History表記錄。這里有個(gè)容易誤操作的點(diǎn)手動(dòng)往__EFMigrationsHistory表插記錄來(lái)欺騙系統(tǒng)認(rèn)為某個(gè)遷移已經(jīng)執(zhí)行過(guò)。偶爾遇到緊急情況可以臨時(shí)用但事后必須補(bǔ)上對(duì)應(yīng)的表結(jié)構(gòu)變更否則生產(chǎn)環(huán)境遲早暴雷。我個(gè)人的原則是遷移歷史必須和數(shù)據(jù)庫(kù)結(jié)構(gòu)完全一致寧可重來(lái)也絕不濫改歷史表。最后想提醒一句EF框架用到后面會(huì)發(fā)現(xiàn)真正決定你用得順不順手的其實(shí)不是ORM本身而是你對(duì)數(shù)據(jù)庫(kù)的尊重程度。該建的索引要建該收斂的查詢一定要收斂該寫(xiě)遷移就寫(xiě)遷移別拿手改數(shù)據(jù)庫(kù)當(dāng)捷徑。把這套習(xí)慣養(yǎng)成了無(wú)論項(xiàng)目換到EF6還是EF Core你都能比絕大多數(shù)人少踩一半的坑。