由于破壞了向后兼容性，Entity Framework的名聲相當(dāng)不光彩，但與Entity Framework Core的完全重寫相比就相形見絀了。在本文中，InfoQ將著眼于其中部分主要特性的變化及其影響。

延期及棄用的特性

首先，我們將看下那些EF Core 1.0沒有支持并且也不在EF Core 1.1路線圖上的EF 6特性。

延遲加載

一般來說，對于Entity Framework和ORM而言，延遲加載一直是一個(gè)備受爭議的問題。EF最初就不應(yīng)該支持延遲加載，因?yàn)樗苋菀妆徽`用，而且經(jīng)常導(dǎo)致性能問題。

不過，在性能不是很重要的情況下，比如快速原型和實(shí)用工具，延遲加載還是非常有用的。因此，第二個(gè)主要版本EF 4增加了這一特性。（注意：為了與.NET Framework的版本號保持一致，EF跳過了版本2和3。）

EF Core沒有提供延遲加載，這讓一些人歡呼，也讓其他人錯(cuò)愕。目前的建議是等待EF Core 1.1，到時(shí)候，他們“可能會允許你推出自己的延遲加載?！备鶕?jù)GitHub及其他地方的各種討論，還不清楚他們是否會直接支持它。

GROUP BY轉(zhuǎn)譯

這一點(diǎn)令人難以理解。雖然LINQ to SQL在10年前就提供了支持，但EF Core的路線圖上并沒有GROUP BY支持。這意味著，如果你的查詢中包含分組操作，EF Core將在查詢生成的時(shí)候忽略GROUP BY子句。

顯而易見的結(jié)果是，這將極大地增加網(wǎng)絡(luò)帶寬要求，因?yàn)樗械牡讓訑?shù)據(jù)都需要在聚合之前移到中間層。反序列化額外的數(shù)據(jù)也是有開銷的，而且，在執(zhí)行實(shí)際的分組操作時(shí)，C#的效率很有可能比數(shù)據(jù)庫低。（數(shù)據(jù)庫的優(yōu)勢是可以使用表的統(tǒng)計(jì)信息，如表的大小和分布，確定使用的最佳算法。）

存儲過程

微軟另一個(gè)讓人吃驚的舉措是不支持存儲過程。雖然從技術(shù)上講你仍然可以使用原始SQL訪問它們，但那有許多限制。

• SQL查詢只能用于返回作為模型組成部分的實(shí)體類型。[該特性計(jì)劃在.NET Core 1.1中提供。]

• SQL查詢必須為實(shí)體類型的所有屬性返回?cái)?shù)據(jù)。

• 結(jié)果集中的列名必須與屬性映射的列名相匹配。注意，這點(diǎn)和EF6.x不同。在EF6.X中，在使用原始SQL查詢時(shí)，屬性/列映射會被忽略，結(jié)果集列名必須和屬性名匹配。

• SQL查詢不能包含關(guān)聯(lián)數(shù)據(jù)。然而，在許多情況下，你可以使用Include操作符組合查詢返回關(guān)聯(lián)數(shù)據(jù)（參見“包含關(guān)聯(lián)數(shù)據(jù)”）。

在某些情況下，你可以將原始SQL和LINQ表達(dá)式混合，比如向表-值函數(shù)查詢添加Where或OrderBy調(diào)用。

空間數(shù)據(jù)類型

空間數(shù)據(jù)類型的情況比較有趣。當(dāng)直接使用ADO.NET時(shí)，他們希望開發(fā)人員使用隨SQL Server提供的、作為COM庫（Microsoft.SqlServer.Types）封裝器的空間類型。由于COM不能很好地與.NET融合，尤其是在庫的分發(fā)和注冊要求方面，所以Entity Framework平行開發(fā)了自己的空間類型（System.Data.Spatial）集。這兩種API都是以開放地理空間聯(lián)盟（OGC）規(guī)范為基礎(chǔ)，因此在基本功能方面非常相似。

目前為止，我們討論的內(nèi)容主要和SQL Server相關(guān)。其他數(shù)據(jù)庫會有其他的空間類型實(shí)現(xiàn)。因此，就可以理解，微軟為什么正在花時(shí)間設(shè)法解決這個(gè)問題。

種子數(shù)據(jù)

雖然EF Core支持?jǐn)?shù)據(jù)庫遷移，但不支持操作種子數(shù)據(jù)查找表。

簡單命令攔截

命令攔截廣泛應(yīng)用于消除Entity Framework SQL生成器的局限。例如，如果你希望在EF中使用全文搜索，則需要實(shí)現(xiàn)IDbCommandInterceptor接口，并重寫ReaderExecuting/ScalarExecuting方法。

這項(xiàng)技術(shù)相當(dāng)復(fù)雜，而且嚴(yán)重依賴于確切地知道EF會生成什么SQL。但是，沒有這項(xiàng)技術(shù)，數(shù)據(jù)庫的許多高級特性都無法使用了。

工具

之前的文章中已經(jīng)提到過，最初隨LINQ to SQL和Entity Framework提供的圖形建模工具不會出現(xiàn)在EF Core中。

而且，目前沒有計(jì)劃提供從數(shù)據(jù)庫更新模型的能力。在可預(yù)見的未來，從數(shù)據(jù)庫生成模型仍然會是一個(gè)一次性事件。

EF Core 1.1的特性

EF Core 1.1有望在明年1季度發(fā)布，除了Bug修復(fù)外，還包含以下特性。

改進(jìn)轉(zhuǎn)譯

這個(gè)麻煩的標(biāo)題缺少細(xì)節(jié)信息。它只是介紹說，“讓更多的查詢成功執(zhí)行，在數(shù)據(jù)庫（而不是內(nèi)存）中進(jìn)行更多的邏輯求值?！彼€介紹說，EF 6支持“簡單”、“中等”和“復(fù)雜”查詢。EF Core的中等查詢已經(jīng)“穩(wěn)定”，復(fù)雜查詢支持還在開發(fā)中。

關(guān)于涵蓋哪些場景的線索很少，所以開發(fā)人員需要格外仔細(xì)地檢查生成的SQL，并分析它們的數(shù)據(jù)庫調(diào)用，以確保EF行為正常。

類似地，使用了導(dǎo)航屬性的查詢被認(rèn)為仍處于開發(fā)中。

查詢非模型類型

如上文所述，EF Core 1.1有望能夠物化不是模型組成部分的類型。

DbSet.Find

這是EF 5提供的一個(gè)方便的方法，用于通過主鍵加載記錄，無需顯式指定名稱。它鉤入上下文緩存，因此避免了不必要的數(shù)據(jù)庫調(diào)用。它還可以找到已經(jīng)附加到上下文但尚未保存到數(shù)據(jù)庫（前提是你沒有使用identity/auto-number列）的記錄。

EntityEntry/ObjectStateEntry APIs

更多EntityEntry及ObjectStateEntry特性，如Reload、GetModifiedProperties、GetDatabaseValues，同樣也在計(jì)劃里。

顯式加載

不要同“主動加載”混淆，顯式加載允許將子集合加載到已經(jīng)物化的實(shí)體中?？梢詫⑺闯墒茄舆t加載外加一個(gè)額外的步驟。

連接恢復(fù)能力

這是一個(gè)很有前景的特性，它會自動重試因?yàn)檫B接問題導(dǎo)致失敗的事務(wù)?！斑@在連接到SQL Azure時(shí)特別有用，在那種情況下，瞬時(shí)錯(cuò)誤很常見?！?/p>

EF Core下一個(gè)版本的特性

雖然預(yù)計(jì)不會在EF Core 1.1的時(shí)間框架內(nèi)完成，但有些其他的特性正在準(zhǔn)備中：

• 復(fù)雜/值類型是沒有主鍵的類型，用于表示實(shí)體類型上的一組屬性；

• 簡單類型轉(zhuǎn)換，如string=>xml；

• 從已有的數(shù)據(jù)庫進(jìn)行模型逆向工程的Visual Studio向?qū)А?/p>

原文地址：http://www.infoq.com/cn/news/2016/08/EF-Core-Roadmap

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關(guān)注

總結(jié)

以上是生活随笔為你收集整理的Entity Framework Core延期及弃用的特性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。