Ado.Net，用了N多年，Entity Framework也關注了很多年。 每當項目轉型的時候，就花費大巴的時間，學習一番，潮流的東西。 這個Orm很多，這個EF很火，這么多年了，我還是不敢用，雖然比當年好多了。
當年也就是12年的時候，實體類是亂七八糟的一大堆，屬性里是帶功能的，不是單純的實體類。而且，其他數據庫支持的不是特別好。現在，實體類清麗了 很多，想着，用一下吧，卻又把我嚇到了，其實也沒有特別的不好，只是太亂了。 EF 官方的增刪該查，最好的就是查詢，剩下的三個，不敢恭維，基本的功能還行，如果涉及到批量的操作，就沒轍了（自己寫擴展除外）
據說，Entity Framework.Extend 擴展的不錯，社群里，一大票人都知道，也都看過，怎么到我這，就是越看越不敢用，越看越不放心了。
批量操作，可以說是一大特色，卻這個批量操作，寫起來倒是很順溜，仔細一研究，他是直接就生成sql語句執行了，而且還是自己生成了個Command執行的，EF的攔截器根本攔截不到
緩存，倒是挺不錯的，這也是個重要的功能，也就是用了EF.Extend的緩存
AuditLog，這個日志審計功能，完全就不該存在，這樣說是因為，通過批量操作的，都無法 審計記錄。
為什么，我不敢用EF呢？
前些年是DataBase First，后來是Mode First，現在是Code First，既然這樣迭代，肯定是EF在改進。但是，我覺得，越改越凌亂了。Code First，讓代碼更加的繁瑣了，關鍵是，C#代碼聲明的實體映射與數據庫不一樣，是會報錯的，例如，字段的長度 不一樣。而，我只是想 用一下 linq 的溜溜的寫法，不再去拼接sql語句。用了EF之后，太多的束縛，如果EF能精簡就好多了，而我又精力有限，寫不了 Orm 了。 只能自己寫Sql了。
其實，我需要的只是，一個精簡的EF
個人覺得，我自己寫的代碼，除了不能Linq，其他的都還好，有 延遲加載，有緩存，有實體生成工具。
這樣挺好，待下次了再學習EF 吧。如果哪個項目，必須要用EF，那我就跟着大拿用吧，讓我自己用，肯定是不會用的。
有這么個業務邏輯，怎么實現
1 如果用EF，寫這么個邏輯是沒辦法正常執行的 2 1、先保存一個對象 3 2、刪除ID>5的數據 4 3、保存一個對象 5 4、修改ID>5的對象，（條件里包含第一次保存的對象） 6 然后，EF，貌似實現不了這樣的事務
正常的代碼應該是類似這樣的
1 using (TransactionScope transaction = new TransactionScope()) 2 { 3 t.Area.Add(new Area() { Code = "A", Name = "A" }); 4 var dfe4 = from a in t.Area where a.Id > 5 select a; 5 dfe4.Delete(); 6 t.Area.Add(new Area() { Code = "B", Name = "B" }); 7 (from a in t.Area where a.Id > 5 select a).Update(a2 => new Area() { Name = "IM:" }); 8 9 var f234 = from a in t.Area where a.Id > 5 && a.Name == "IM:" select a; 10 Area a234 = f234.First(); 11 if (a234 != null) 12 { 13 a234.Name = "IM:234"; 14 Area a235 = f234.Where(e => e.Id == a234.Id + 2).FirstOrDefault(); 15 if (a235 != null) 16 { 17 t.Area.Remove(a235); 18 } 19 } 20 t.SaveChanges(); 21 Console.WriteLine("------------"); 22 Console.ReadLine(); 23 transaction.Complete(); 24 }
這是使用了 EntityFramework.Extend的寫法。 這樣執行會有問題么？
請看這兩張圖
執行順序不對你說，如果是在一個系統內，恰好有先后順序的依賴關系，那就真的出問題了。