這是一個很有意思的問題，我們一步一步來探討，首先需要明確兩個概念（來自 MSDN）：

• IQueryable：提供對未指定資料型別的特定資料來源的查詢進行計算的功能。
• IEnumerable：公開列舉數，該列舉數支援在非泛型集合上進行簡單迭代。

IQueryable 繼承自 IEnumerable，它們倆最大的區別是，IQueryable 是表示式樹處理，可以延遲查詢，而 IEnumerable 只能查詢在本地記憶體中，Repository 的概念就不多說了，在“偽 DDD”設計中，你可以把它看作是資料訪問層。

下面我們先實現 Repository 返回 IEnumerable：

public interface IBookRepository  
{
    Book GetById();
    IEnumerable<Book> GetAllBooks();
    IEnumerable<Book> GetBy....();
    void Add(Book book);
    void Delete(Book book);
    void SaveChanges();
}
 

上面是我們的一般介面設計，包含查詢、增加、刪除操作，你發現並沒有修改，其實我們可以先通過 GetById 操作，然後取得 Book 物件，進行修改，最後執行 SaveChanges 就可以了，在持久化資料庫的時候，會判斷實體狀態值的概念，最後進行應用改變。

GetBy....() 代表了一類查詢方法，因為我們的業務比較複雜，對 Book 的查詢會千奇百怪，所以，沒有辦法，我們只能增加各類查詢方法來滿足需求，最後可能導致的結果是，一個 Where 對應一個查詢方法，IBookRepository 會充斥著各類查詢方法，並且這些查詢方法一般只會被一個 Application 方法呼叫，如果你檢視下 GetBy....() 方法實現，會發現其實都大同小異，不同的只是 Where 條件，這樣的結果就會導致程式碼變得非常的臃腫。

針對上面的問題，怎麼辦呢？因為 IEnumerable 是查詢在本地記憶體中，所以沒有辦法，我們只能這樣處理，那如何使用 IQueryable 會是怎樣的呢？我們看下程式碼：

public interface IBookRepository  
{
    IQueryable<Book> GetBooks();
    void Add(Book book);
    void Delete(Book book);
    void SaveChanges();
}

只有一個 GetBooks 查詢，那它能滿足各類查詢需求嗎？我們看下 Application 中呼叫的程式碼：

public class BookApplication : IBookApplication  
{
    private IBookRepository _bookRepository;

    public BookApplication(IBookRepository bookRepository)
    {
        _bookRepository = bookRepository;
    }

    public IEnumerable<Book> GetAllBooks()
    {
        return _bookRepository.GetBooks().AsEnumerable();
    }

    public IEnumerable<Book> GetBooksByUser(int userId)
    {
        return _bookRepository.GetBooks().Where(b => b.UserId == userId).AsEnumerable();
    }

    //....
}
 

因為 IQueryable 是延遲查詢，只有在執行 AsEnumerable 的時候，才會真正去查詢，也可以這麼說，BookApplication 可以根據需求任意構建查詢表示式樹，就像我們在 SQL Server 中寫查詢 SQL，SELECT * FORM Books 在 BookRepository 中進行構建，WHERE ... 操作在 BookApplication 中進行構建，最後的 F5 執行也在 BookApplication 中。

從上面的程式碼中，我們可以看到，IQueryable 很好的解決了使用 IEnumerable 所出現的問題，一個查詢可以應對千變萬化的應用查詢，IQueryable 看起來好像是那麼的強大，其實 IQueryable 的強大並不限於此，上面說的是查詢表示式，那新增、修改和刪除操作，可以使用它進行完成嗎？修改和刪除是可以的，新增並不能，具體可以參考 dudu 的這篇博文：開發筆記：基於EntityFramework.Extended用EF實現指定欄位的更新。

關於 EntityFramework.Extended 的擴充套件，需要記錄下，因為這個東西確實非常好，改變了我們之前的很多寫法和問題，比如，在之前使用 EF 進行修改和刪除實體，我們一般會這些寫：

public class BookApplication : IBookApplication  
{
    private IBookRepository _bookRepository;

    public BookApplication(IBookRepository bookRepository)
    {
        _bookRepository = bookRepository;
    }

    public void UpdateNameById(int bookId, string bookName)
    {
        var book = _bookRepository.GetById(bookId);
        book.BookName = bookName;
        _bookRepository.SaveChanges();
    }

    public void UpdateNameByIds(int[] bookIds, string bookName)
    {
        var books = _bookRepository.GetBooksByIds(bookIds);
        foreach (var book in books)
        {
            book.BookName = bookName;
        }
        _bookRepository.SaveChanges();
    }

    public void Delete(int id)
    {
        var book = _bookRepository.GetById(id);
        _bookRepository.Delete(book);//context.Books.Remove(book);
        _bookRepository.SaveChanges();
    }
}

上面的寫法有什麼問題呢？其實最大的問題就是，我們要進行修改和刪除，必須先獲取這個實體，也就是先查詢再進行修改和刪除，這個就有點多餘了，尤其是 UpdateNameByIds 中的批量修改，先獲取 Book 物件列表，然後再遍歷修改，最後儲存，是不是有點 XXX 的感覺呢，仔細想想，還不如不用 EF 來的簡單，因為一個 Update SQL 就可以搞定，簡單並且效能又高，為什麼還要使用 EF 呢？這是一個坑？其實使用 EF 也可以執行 SQL，但這就像換了個馬甲，沒有什麼卵用。

針對上面的問題，該如何解決呢？很簡單，使用 EntityFramework.Extended 和 IQueryable 就可以，我們改造下上面的程式碼：

using EntityFramework.Extensions;

public class BookApplication : IBookApplication  
{
    private IBookRepository _bookRepository;

    public BookApplication(IBookRepository bookRepository)
    {
        _bookRepository = bookRepository;
    }

    public void UpdateNameById(int bookId, string bookName)
    {
        IQueryable<Book> books = _bookRepository.GetBooks();
        books = books.Where(b => b.bookId == bookId);
        books.Update<Book>(b => new Book { BookName = bookName });
    }

    public void UpdateNameByIds(int[] bookIds, string bookName)
    {
        IQueryable<Book> books = _bookRepository.GetBooks();
        books = books.Where(b => bookIds.Contains(bookIds));
        books.Update<Book>(b => new Book { BookName = bookName });
    }

    public void Delete(int id)
    {
        IQueryable<Book> books = _bookRepository.GetBooks();
        books = books.Where(b => b.bookId == id);
        books.Delete<Book>();
    }
}

有沒有發現什麼不同呢？原來 IQueryable 還可以這樣寫？這貨居然不只是用於查詢，也可以用於刪除和修改，另外，通過追蹤生成的 SQL 程式碼，你會發現，沒有了 SELECT，和我們直接寫 SQL 是一樣的效果，在執行修改和刪除之前，我們需要對查詢表達樹進行過濾，也就是說的，當我們最後應用修改的時候，會是在這個過濾的查詢表達樹基礎上的，比如上面的 Delete 操作，我們先通過 bookId 進行過濾，然後直接進行 Delete 就可以了，哇塞，原來是這樣的簡單。

當 BookApplication 操作變的簡單的時候，BookRepository 也會相應變的簡單：

public interface IBookRepository  
{
    IQueryable<Book> GetBooks();
    void SaveChanges();//只用於Books.Add(book);
}

一個 IQueryable 表達樹，一個 SaveChanges 操作，就可以滿足 BookApplication 中的所有操作。

既然 IQueryable 是這麼的強大，那用它就好了，為什麼還要討論呢？如果你 Google 搜尋“Repository IQueryable”關鍵詞，會發現大量的相關文章，我先貼出幾個非常讚的討論：

上面只是部分，關於這類的文章，老外寫的非常多，而且評論中的討論也非常激烈，因為英語實在差，我大概看了一些，出乎我意料之外的是，很多人都不贊成 Repository 返回 IQueryable，但討論的卻非常有意思，比如有個老外這樣感嘆：I'm still not convinced that returning IQueryable is a bad idea, but at least I'm far more aware of the arguments against it. 大致意思是：我仍然不相信返回 IQueryable 是一個壞主意，但至少我更瞭解他們的反對理由，是不是很有意思呢？

關於 Repository 返回 IQueryable 的討論，我大致總結下：

好處：

1. 延遲執行。
2. 減少 Repository 重複程式碼（GetBy...）。
3. IQueryable 提供更好的靈活性。
4. ...

壞處：

1. 隔離單元測試。
2. 資料訪問在 Repository 之外完成。
3. 資料訪問異常在 Repository 之外丟擲。
4. 該領域層將充斥著這些相當詳細查詢。
5. ...

好處就不多說了，因為我們上面已經實踐過了，關於壞處，“隔離單元測試”是什麼意思呢？也就是說我們不能很好的對 Repository 進行單元測試，一方面是因為 IRepository 是那麼的簡單（就兩個方法），另一方面 IQueryable 是查詢表達樹，它並不是完成時，只有在具體呼叫的時候才會查詢完成，所以，對於 Repository 的單元測試，顯然是沒有任何意義的。

關於 Repository Pattern and IQueryable 這篇博文，我想再說一下，因為這個老外的觀點非常贊，首先，它是基於 Repository 模式概念基礎上說的，所以，我們一開始說：在“偽 DDD”設計中，你可以把 Repository 看作是資料訪問層。這是兩個不同的前提，我再大致總結下這個老外的觀點：

• However the mistake is not the IQueryable itself, but its purpose.（不是 IQueryable 本身的錯誤，而是它的目的。）
• The point is that using IQueryable, you're asking for a query builder and not for a model.（問題的關鍵是，使用 IQueryable 是一個查詢生成器，而不是一個模型。）
• we want to specify what to get, not how to get it.（我們想通過規約得到它，而不是怎樣去得到。）
• tell it the what, not the how.

看了上面，是不是有點豁然開朗的感覺呢，其實從 Repository 的模式概念方面考慮，使用 IQueryable 確實不是很恰當，但不可否認的是，IQueryable 又這麼強大和便利，怎麼辦呢？就像博文一開始強調的那樣：Repository 的概念就不多說了，在“偽 DDD”設計中，你可以把它看作是資料訪問層。

所以呢，如果你的專案是“偽 DDD”，並且 Repository 是被你看作“資料訪問層”，那麼使用 IQueryable 就沒啥問題了。