OData IEnumerable 或 IQueryable

Question

我對 OData v3/v4 還是很陌生，並使用 Visual Studio 中的 OData Connect 服務從 OData 服務器獲取數據。 現在我的問題是什么是獲取數據最好、最快的方法，然后用自己的集合驗證它？

例如，我們有一個Employee類型的Microsoft.OData.Client.DataServiceQuery我們想要從服務器獲取所有員工並將其與我們的本地數據集進行比較，例如來自另一個 CRM 系統的List(Of Employee)

例如，要從 OData 服務獲取數據，我們必須設置DataServiceQuery ：獲取所有員工的簡單方法是DataServiceQuery.GetAllPages ，它返回一個IEnumerable(Of Employee) ，我們可以在其上調用.ToList function。 在此之后，我們可以使用 LINQ 和/或 LAMBDA 在兩個列表之間進行所有比較和更新集合。

但是現在如果我通過使用DataServiceQuery.Take(Number)改變方法，那么它返回一個IQueryable(Of Employee) ，我們也可以在其上調用.ToList或者使用IQueryable是否不必要？

所以我的問題是從 OData v4 服務器獲取所有數據然后將其填充到 memory 然后使用 LINQ 和/或 Z64CD1DD4B2628444BAE372942CC36E91 的最佳方法是什么？

Answer 1

您的兩個解決方案實際上都會做同樣的事情，唯一的區別是通過使用.Take()在這種情況下您正在編寫一個查詢，它將從服務器批量處理數據，您可能更熟悉這個被引用作為Paging 。

在 OData 服務器邏輯中，IEnumerable 和 IQueryable 之間的區別非常重要，因為 IQueryable 會延遲到您迭代查詢之前，像.ToList()這樣的調用將強制進行此迭代。

然而，在客戶端，即使數據類型是Linq IQueryable類型，當您完成查詢時，您只能迭代一次，這對於來自DataServiceQuery的IEnumerable響應也是如此。

但是現在如果我通過使用 DataServiceQuery.Take(Number) 來改變方法，那么它會返回一個 IQueryable(Of Employee)，我們也可以在其上調用 the.ToList 或者 IQueryable 是否不需要？

特別是對於DataServiceQuery ，鑒於我們只能迭代一次響應，作為一般模式，我們通常會調用.Tolist .Tolist()來強制接收來自服務器的響應，因此很明顯這是我們的意圖。

• 這不是必要與否的問題，而是有意下載數據一次，並將其存儲在允許我們再次迭代它的列表變量中。

IQueryable響應允許您在將其發送到服務器之前構建過濾器、訂單和投影表達式，在 OData 術語中，這應該轉換為要發送的$filter 、 $orderby 、 $expand 、 $select 、 $skip和$top查詢選項與 HTTP 請求。 如果您要應用其中任何一個，它會提高性能，但這似乎不適用於這里。

因此，關於您的問題，由於您正在獲取所有數據，因此來自DataServiceQuery的這兩種類型的響應之間沒有性能差異。 當您不想要所有行時，就會出現一個事實：

如果您使用Where()或ApplyQueryOption() ) 或 .Take( .Take()限制了記錄的數量，那么由於有效負載將小於非限制查詢，它將返回更快，這完全是因為通過網絡傳輸的數據有效負載是更小。

如果您要調用.ToList()然后應用過濾或限制，則必須首先下載整個集合，然后才能評估您的過濾器，因此您可以通過使用IQueryable並在執行之前應用過濾條件來獲得最佳性能它。

同樣，對於您的特定任務，因為它涉及對整個集合進行迭代，因此兩者都沒有任何固有的優勢。 如果記錄集很大，我鼓勵您使用批處理/分頁來處理較小集中的記錄，以免鎖定服務器資源，並且不會用完 memory 試圖反序列化整個結果集單次操作。

---

無論哪種方式，這些類型的數據同步通常都是昂貴的過程，但是通過在客戶端上執行此操作，您可能選擇了效率最低的機制。

如果可以的話，這個任務應該在服務器端執行，這樣你可以減少一個完整的數據比較往返

---

如果無法在服務器上執行比較，那么也許您可以將您的比較公式化為IQueryable表達式，只返回匹配的或不匹配的結果，這就是IQueryable發揮威力的地方，它將通過表達式到服務器以直接在數據庫中執行比較。