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，那我就跟着大拿用吧，讓我自己用，肯定是不會用的。
有這麼個業務邏輯，怎麼實作
正常的代碼應該是類似這樣的
這是使用了 EntityFramework.Extend的寫法。 這樣執行會有問題麼？
請看這兩張圖
執行順序不對你說，如果是在一個系統内，恰好有先後順序的依賴關系，那就真的出問題了。