Repository 返回 IQueryable？仍是 IEnumerable？（轉）

轉載：本文轉載自： https://www.cnblogs.com/xishuai/p/repository-return-iqueryable-or-ienumerable.html

做者：田園裏的蟋蟀

出處： http://www.cnblogs.com/xishuai/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文連接，不然保留追究法律責任的權利。

 

這是一個頗有意思的問題，咱們一步一步來探討，首先須要明確兩個概念（來自 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」關鍵詞，會發現大量的相關文章，我先貼出幾個很是讚的討論：

• Should Repositories return IQueryable?
• Repository Return IQueryable
• Should you return IQueryable from Your Repositories?
• What are alternatives to using IQueryable in Repository Pattern?
• IQueryable vs List: What Should Your Repository Return?
• Should my repository expose IQueryable?
• Repository Pattern and IQueryable（簡潔而有力）
• Why the Repository Pattern Is Still Valid

上面只是部分，關於這類的文章，老外寫的很是多，並且評論中的討論也很是激烈，由於英語實在差，我大概看了一些，出乎我意料以外的是，不少人都不同意 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 就沒啥問題了。