Entity Framework Core延期及棄用的特性

責任編輯:editor004

作者:Jonathan Allen

2016-08-09 12:26:51

摘自:INFOQ

由于破壞了向后兼容性,Entity Framework的名聲相當不光彩,但與Entity Framework Core的完全重寫相比就相形見絀了。

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

延期及棄用的特性

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

延遲加載

一般來說,對于Entity Framework和ORM而言,延遲加載一直是一個備受爭議的問題。EF最初就不應該支持延遲加載,因為它很容易被誤用,而且經常導致性能問題。

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

EF Core沒有提供延遲加載,這讓一些人歡呼,也讓其他人錯愕。目前的建議是等待EF Core 1.1,到時候,他們“可能會允許你推出自己的延遲加載。”根據GitHub及其他地方的各種討論,還不清楚他們是否會直接支持它。

GROUP BY轉譯

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

顯而易見的結果是,這將極大地增加網絡帶寬要求,因為所有的底層數據都需要在聚合之前移到中間層。反序列化額外的數據也是有開銷的,而且,在執(zhí)行實際的分組操作時,C#的效率很有可能比數據庫低。(數據庫的優(yōu)勢是可以使用表的統計信息,如表的大小和分布,確定使用的最佳算法。)

存儲過程

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

SQL查詢只能用于返回作為模型組成部分的實體類型。[該特性計劃在.NET Core 1.1中提供。] SQL查詢必須為實體類型的所有屬性返回數據。 結果集中的列名必須與屬性映射的列名相匹配。注意,這點和EF6.x不同。在EF6.X中,在使用原始SQL查詢時,屬性/列映射會被忽略,結果集列名必須和屬性名匹配。 SQL查詢不能包含關聯數據。然而,在許多情況下,你可以使用Include操作符組合查詢返回關聯數據(參見“包含關聯數據”)。

在某些情況下,你可以將原始SQL和LINQ表達式混合,比如向表-值函數查詢添加Where或OrderBy調用。

空間數據類型

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

目前為止,我們討論的內容主要和SQL Server相關。其他數據庫會有其他的空間類型實現。因此,就可以理解,微軟為什么正在花時間設法解決這個問題。

種子數據

雖然EF Core支持數據庫遷移,但不支持操作種子數據查找表。

簡單命令攔截

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

這項技術相當復雜,而且嚴重依賴于確切地知道EF會生成什么SQL。但是,沒有這項技術,數據庫的許多高級特性都無法使用了。

工具

之前的文章中已經提到過,最初隨LINQ to SQL和Entity Framework提供的圖形建模工具不會出現在EF Core中。

而且,目前沒有計劃提供從數據庫更新模型的能力。在可預見的未來,從數據庫生成模型仍然會是一個一次性事件。

EF Core 1.1的特性

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

改進轉譯

這個麻煩的標題缺少細節(jié)信息。它只是介紹說,“讓更多的查詢成功執(zhí)行,在數據庫(而不是內存)中進行更多的邏輯求值。”它還介紹說,EF 6支持“簡單”、“中等”和“復雜”查詢。EF Core的中等查詢已經“穩(wěn)定”,復雜查詢支持還在開發(fā)中。

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

類似地,使用了導航屬性的查詢被認為仍處于開發(fā)中。

查詢非模型類型

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

DbSet.Find

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

EntityEntry/ObjectStateEntry APIs

更多EntityEntry及ObjectStateEntry特性,如Reload、GetModifiedProperties、GetDatabaseValues,同樣也在計劃里。

顯式加載

不要同“主動加載”混淆,顯式加載允許將子集合加載到已經物化的實體中??梢詫⑺闯墒茄舆t加載外加一個額外的步驟。

連接恢復能力

這是一個很有前景的特性,它會自動重試因為連接問題導致失敗的事務。“這在連接到SQL Azure時特別有用,在那種情況下,瞬時錯誤很常見。”

EF Core下一個版本的特性

雖然預計不會在EF Core 1.1的時間框架內完成,但有些其他的特性正在準備中:

復雜/值類型是沒有主鍵的類型,用于表示實體類型上的一組屬性; 簡單類型轉換,如string=>xml; 從已有的數據庫進行模型逆向工程的Visual Studio向導。

查看英文原文:Delayed and Deprecated Features in Entity Framework Core

鏈接已復制,快去分享吧

企業(yè)網版權所有?2010-2024 京ICP備09108050號-6京公網安備 11010502049343號