LINQ到實體 - 實體框架

Question

我期待得到的時候，我們應該過目IQueryable使用IEnumerable與LINQ到實體更好地理解。

對數據庫的真正基本調用，IQueryable是更快，但我什麼時候需要考慮在其位置使用IEnumerable？

其中是IEnumerable最佳了一個多IQueryable？

Answer 1

基本上，IQueryables由查詢提供者（例如，數據庫）執行，並且一些操作不能或不應由數據庫來完成。例如，如果你想用你，你可以嘗試類似的數據庫有一個值調用C＃函數（這裏作爲一個例子，正確大寫名稱）;

db.Users.Select(x => Capitalize(x.Name)) // Tries to make the db call Capitalize. 
     .ToList(); 

由於Select是在一個IQueryable執行，以及底層的數據庫沒有你Capitalize功能的想法，查詢將失敗。你可以做的是從數據庫中獲取正確的數據，並將IQueryable轉換爲IEnumerable（這基本上只是一種迭代內存集合的方法），以便在本地內存中執行剩餘的操作，如;

db.Users.Select(x => x.Name)    // Gets only the name from the database 
     .AsEnumerable()     // Do the rest of the operations in memory 
     .Select(x => Capitalize(x))  // Capitalize in memory 
     .ToList(); 

，當涉及到對的IEnumerable IQueryable的性能從EF的一面，最重要的是，你應該始終嘗試使用一個IQueryable儘可能少的數據儘可能得到過濾數據轉換爲IEnumerable。 AsEnumerable調用的基本功能是告訴數據庫「現在過濾數據給我」，如果你沒有過濾數據，你會得到所有內容，甚至可能不需要的數據。

Answer 2

IEnumerable代表一個元素序列，您可以逐個枚舉，直到找到需要的答案爲止，例如，如果我想要所有屬性大於10的實體，則需要遍歷每個元素轉動並只返回那些匹配的。拉一個數據庫表的每一行到內存中爲了做到這一點不會，也許是一個好主意。

在另一方面IQueryable表示一組在其上象濾波操作可以推遲到底層數據源元件的，所以在濾波的情況下，如果我的自定義數據源的頂部（或使用實施IQueryable LINQ到實體！），那麼我可以給過濾的辛勤工作/分組等數據源（如數據庫）。

IQueryable的主要缺點是實現它非常困難 - 將查詢構造爲表達式樹，然後作爲實現者解析查詢。如果你不打算寫一個提供者，那麼這不會傷害你。

IQueryable的另一個值得注意的方面（儘管這只是關於將處理傳遞給另一個可能對世界做出不同假設的系統的一般警告），因爲您可能會發現字符串比較等工作它們在源系統中被支持的方式，而不是它們被消費者實現的方式，例如如果您的源數據庫不區分大小寫，但.NET中的默認比較區分大小寫。