EF Core 2.1路線圖：視圖、GROUP BY和惰性載入

Entity Framework Core一直追隨著初始Entity Framework的發展，並不斷推陳出新。它首先推出的是對視圖的支持，這聽起來有些聳人聽聞。在即將推出的EF Core 2.1之前，EF Core並未對資料庫視圖提供官方的支持，也不支持缺少主鍵的資料庫表，儘管後一種情況十分罕見。

EF Core 2.0提供了一種變通方案。開發人員可以使用ROW_NUMBER創建一個代理主鍵，和聲明資料庫表一樣去聲明視圖。此後，就可以將視圖視為資料庫表，配置資料庫的上下文。

但是開發人員不能修改視圖返回ROW_NUMBER，因為列的組合併非是唯一的。開發人員可以使用屬性隨機標記列，然後使用迴避EF的緩存邏輯，以免遺棄了一些「重複」的行。

在EF Core 2.1中，支持採用另一種做法。開發人員可以設置視圖的「查詢類型」，或將內聯（inline）SQL設置為「只讀」的。這樣，不再需要資料庫表必須具有主鍵。

對GROUP BY的支持

在EF Core中，另一個出乎意料的限制是不支持生成SQL中的GROUP BY操作。當前，整個數據集在傳送到客戶端後，EF Core需在內存中執行分組操作。和在資料庫中執行分組操作相比，EF Core的操作將會導致明顯更高的網路、內存和CPU佔用。

隨著EF Core 2.1的發布，分組操作的執行變通為在視圖中或內聯SQL中進行。之後，開發人員可以使用上述解決方法，即將視圖看成是資料庫表。

惰性載入（Lazy Loading）

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

要啟用惰性載入，對象中必須具有一個接受參數的構造函數。集合（Collection）屬性需要遵循如下模式編寫：

public ICollection

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

在本例中，就是上面提及的由構造函數提供的對象。是一個回調EF Core的擴展函數。

和初始的EF版本一樣，在未來的EF Core版本中，有望無需編寫此類「八股代碼」（boilerplate code）就可實現惰性載入。

事務

EF Core一直支持事務，但僅局限於支持資料庫事務。在下一版本中，開發人員將可以使用命名空間提供的等功能。該特性也稱為「氛圍事務」（ambient transaction），它支持多個資源間協調事務，包括資料庫、消息隊列、Web服務和文件系統等。例如，開發人員可在對事務NTFS硬碟的寫操作失敗的情況下，自動回滾資料庫更改。

值轉換

對值轉換的支持，是ORM中一個常常被低估的特性。簡而言之，該特性處理諸如將枚舉類型按其底層的整數值或字元串表示存儲等問題。但是如果需要ORM支持多種資料庫引擎，事情就變得十分複雜。

假定數據模型中存在無符號整數。部分資料庫原生地支持無符號整數，因此不存在問題。但是諸如SQL Server等資料庫只支持有符號整數。如果需要數據模型同時支持兩者，那麼ORM具備處理轉換能力就尤為重要。

在EF Core 2.1路線圖中，更進一步支持插入開發人員定製的轉換邏輯。該特性將支持對屬性值的透明加/解密等特性。

空間數據類型

新路線圖收到的首個反饋，就是再次呼籲支持空間數據類型（Spatial Data Type）。空間數據在SQL Server中表示為和類型。兩者間的不同之處在於，用於歐氏（平面）坐標系統，而則用於更為複雜的橢圓坐標系統。

EF Core 2.1對空間數據提供了部分支持。首先，開發需要運行在.NET Framework上，因為.NET Core中並未提供處理空間數據所需的庫。其次，開發人員需要使用視圖或內聯SQL，將幾何和地理數據轉換為WKB（熟知二進位，well-known binary）或WKT（熟知文本，well-known text）。WKB/WKT是表示此類空間數據的工業標準。最後，開發人員可以著手編寫值轉換器（方法如上所述），實現適當的.NET對象與WKB/WKT間的相互轉換。

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！