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 的討論，我大致總結下：

好處：

延遲執行，
減少 Repository 重復代碼（GetBy...），
IQueryable 提供更好的靈活性，
...

壞處：

隔離單元測驗，
資料訪問在 Repository 之外完成，
資料訪問例外在 Repository 之外拋出，
該領域層將充斥著這些相當詳細查詢，
...

好處就不多說了，因為我們上面已經實踐過了，關于壞處，“隔離單元測驗”是什么意思呢？也就是說我們不能很好的對 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 就沒啥問題了，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/220583.html

標籤：領域驅動設計

上一篇：springboot2.x 從零到一（1、快速創建服務）

下一篇：Repository 回傳 IQueryable？還是 IEnumerable？（轉）