Entity Framework Core一直追隨著初始Entity Framework的發(fā)展，并不斷推陳出新。它首先推出的是對(duì)視圖的支持，這聽起來有些聳人聽聞。在即將推出的EF Core 2.1之前，EF Core并未對(duì)數(shù)據(jù)庫視圖提供官方的支持，也不支持缺少主鍵的數(shù)據(jù)庫表，盡管后一種情況十分罕見。

EF Core 2.0提供了一種變通方案。開發(fā)人員可以使用ROW_NUMBER創(chuàng)建一個(gè)代理主鍵，和聲明數(shù)據(jù)庫表一樣去聲明視圖。此后，就可以將視圖視為數(shù)據(jù)庫表，配置數(shù)據(jù)庫的上下文。

但是開發(fā)人員不能修改視圖返回ROW_NUMBER，因?yàn)榱械慕M合并非是唯一的。開發(fā)人員可以使用Key屬性隨機(jī)標(biāo)記列，然后使用AsNoTracking回避EF的緩存邏輯，以免遺棄了一些“重復(fù)”的行。

在EF Core 2.1中，支持采用另一種做法。開發(fā)人員可以設(shè)置視圖的“查詢類型”，或?qū)?nèi)聯(lián)（inline）SQL設(shè)置為“只讀”的。這樣，不再需要數(shù)據(jù)庫表必須具有主鍵。

對(duì)GROUP BY的支持

在EF Core中，另一個(gè)出乎意料的限制是不支持生成SQL中的GROUP BY操作。當(dāng)前，整個(gè)數(shù)據(jù)集在傳送到客戶端后，EF Core需在內(nèi)存中執(zhí)行分組操作。和在數(shù)據(jù)庫中執(zhí)行分組操作相比，EF Core的操作將會(huì)導(dǎo)致明顯更高的網(wǎng)絡(luò)、內(nèi)存和CPU占用。

隨著EF Core 2.1的發(fā)布，分組操作的執(zhí)行變通為在視圖中或內(nèi)聯(lián)SQL中進(jìn)行。之后，開發(fā)人員可以使用上述解決方法，即將視圖看成是數(shù)據(jù)庫表。

惰性加載（Lazy Loading）

我們知道，EF Core中討論最為激烈的特性就是惰性加載。雖然有一些開發(fā)人員樂此不疲，但也另有一些人將其視洪水猛獸，認(rèn)為其中充斥著大量可導(dǎo)致低性能或運(yùn)行時(shí)意外失敗的陷阱。EF Core 2.1中添加了惰性加載特性，但是有別于我們先前在最初的Entity Framework中所看到的。

要啟用惰性加載，對(duì)象中必須具有一個(gè)接受Action<object, string>參數(shù)的構(gòu)造函數(shù)。集合（Collection）屬性需要遵循如下模式編寫：

public ICollectionPosts {get => _lazyLoader.Load(this, ref _posts);set => _posts = value; }

在本例中，_lazyLoader就是上面提及的由構(gòu)造函數(shù)提供的Action對(duì)象。Load是一個(gè)回調(diào)EF Core的擴(kuò)展函數(shù)。

和初始的EF版本一樣，在未來的EF Core版本中，有望無需編寫此類“八股代碼”（boilerplate code）就可實(shí)現(xiàn)惰性加載。

事務(wù)

EF Core一直支持事務(wù)，但僅局限于支持?jǐn)?shù)據(jù)庫事務(wù)。在下一版本中，開發(fā)人員將可以使用System.Transactions命名空間提供的TransactionScope等功能。該特性也稱為“氛圍事務(wù)”（ambient transaction），它支持多個(gè)資源間協(xié)調(diào)事務(wù)，包括數(shù)據(jù)庫、消息隊(duì)列、Web服務(wù)和文件系統(tǒng)等。例如，開發(fā)人員可在對(duì)事務(wù)NTFS硬盤的寫操作失敗的情況下，自動(dòng)回滾數(shù)據(jù)庫更改。

值轉(zhuǎn)換

對(duì)值轉(zhuǎn)換的支持，是ORM中一個(gè)常常被低估的特性。簡而言之，該特性處理諸如將枚舉類型按其底層的整數(shù)值或字符串表示存儲(chǔ)等問題。但是如果需要ORM支持多種數(shù)據(jù)庫引擎，事情就變得十分復(fù)雜。

假定數(shù)據(jù)模型中存在無符號(hào)整數(shù)。部分?jǐn)?shù)據(jù)庫原生地支持無符號(hào)整數(shù)，因此不存在問題。但是諸如SQL Server等數(shù)據(jù)庫只支持有符號(hào)整數(shù)。如果需要數(shù)據(jù)模型同時(shí)支持兩者，那么ORM具備處理轉(zhuǎn)換能力就尤為重要。

在EF Core 2.1路線圖中，更進(jìn)一步支持插入開發(fā)人員定制的轉(zhuǎn)換邏輯。該特性將支持對(duì)屬性值的透明加/解密等特性。

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

新路線圖收到的首個(gè)反饋，就是再次呼吁支持空間數(shù)據(jù)類型（Spatial Data Type）。空間數(shù)據(jù)在SQL Server中表示為Geometry和Geography類型。兩者間的不同之處在于，Geometry用于歐氏（平面）坐標(biāo)系統(tǒng)，而Geography則用于更為復(fù)雜的橢圓坐標(biāo)系統(tǒng)。

EF Core 2.1對(duì)空間數(shù)據(jù)提供了部分支持。首先，開發(fā)需要運(yùn)行在.NET Framework上，因?yàn)?NET Core中并未提供處理空間數(shù)據(jù)所需的庫。其次，開發(fā)人員需要使用視圖或內(nèi)聯(lián)SQL，將幾何和地理數(shù)據(jù)轉(zhuǎn)換為WKB（熟知二進(jìn)制，well-known binary）或WKT（熟知文本，well-known text）。WKB/WKT是表示此類空間數(shù)據(jù)的工業(yè)標(biāo)準(zhǔn)。最后，開發(fā)人員可以著手編寫值轉(zhuǎn)換器（方法如上所述），實(shí)現(xiàn)適當(dāng)?shù)?NET對(duì)象與WKB/WKT間的相互轉(zhuǎn)換。

.NET Core中還規(guī)劃了其它一些特性，可參見EF 2.1路線圖的通訊稿。

原文：http://www.infoq.com/cn/news/2018/03/EF-Core-2.1-Road-Map

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的EF Core 2.1路线图：视图、GROUP BY和惰性加载的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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