這是一個(gè)很有意思的問(wèn)題，我們一步一步來(lái)探討，首先需要明確兩個(gè)概念（來(lái)自 MSDN）：

• IQueryable：提供對(duì)未指定數(shù)據(jù)類(lèi)型的特定數(shù)據(jù)源的查詢(xún)進(jìn)行計(jì)算的功能。
• IEnumerable：公開(kāi)枚舉數(shù)，該枚舉數(shù)支持在非泛型集合上進(jìn)行簡(jiǎn)單迭代。

IQueryable 繼承自 IEnumerable，它們倆最大的區(qū)別是，IQueryable 是表達(dá)式樹(shù)處理，可以延遲查詢(xún)，而 IEnumerable 只能查詢(xún)?cè)诒镜貎?nèi)存中，Repository 的概念就不多說(shuō)了，在“偽 DDD”設(shè)計(jì)中，你可以把它看作是數(shù)據(jù)訪(fǎng)問(wèn)層。

下面我們先實(shí)現(xiàn) Repository 返回 IEnumerable：

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

上面是我們的一般接口設(shè)計(jì)，包含查詢(xún)、增加、刪除操作，你發(fā)現(xiàn)并沒(méi)有修改，其實(shí)我們可以先通過(guò) GetById 操作，然后取得 Book 對(duì)象，進(jìn)行修改，最后執(zhí)行 SaveChanges 就可以了，在持久化數(shù)據(jù)庫(kù)的時(shí)候，會(huì)判斷實(shí)體狀態(tài)值的概念，最后進(jìn)行應(yīng)用改變。

GetBy....() 代表了一類(lèi)查詢(xún)方法，因?yàn)槲覀兊臉I(yè)務(wù)比較復(fù)雜，對(duì) Book 的查詢(xún)會(huì)千奇百怪，所以，沒(méi)有辦法，我們只能增加各類(lèi)查詢(xún)方法來(lái)滿(mǎn)足需求，最后可能導(dǎo)致的結(jié)果是，一個(gè) Where 對(duì)應(yīng)一個(gè)查詢(xún)方法，IBookRepository 會(huì)充斥著各類(lèi)查詢(xún)方法，并且這些查詢(xún)方法一般只會(huì)被一個(gè) Application 方法調(diào)用，如果你查看下 GetBy....() 方法實(shí)現(xiàn)，會(huì)發(fā)現(xiàn)其實(shí)都大同小異，不同的只是 Where 條件，這樣的結(jié)果就會(huì)導(dǎo)致代碼變得非常的臃腫。

針對(duì)上面的問(wèn)題，怎么辦呢？因?yàn)?IEnumerable 是查詢(xún)?cè)诒镜貎?nèi)存中，所以沒(méi)有辦法，我們只能這樣處理，那如何使用 IQueryable 會(huì)是怎樣的呢？我們看下代碼：

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

只有一個(gè) GetBooks 查詢(xún)，那它能滿(mǎn)足各類(lèi)查詢(xún)需求嗎？我們看下 Application 中調(diào)用的代碼：

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();}//.... }

因?yàn)?IQueryable 是延遲查詢(xún)，只有在執(zhí)行 AsEnumerable 的時(shí)候，才會(huì)真正去查詢(xún)，也可以這么說(shuō)，BookApplication 可以根據(jù)需求任意構(gòu)建查詢(xún)表達(dá)式樹(shù)，就像我們?cè)?SQL Server 中寫(xiě)查詢(xún) SQL，SELECT * FORM Books 在 BookRepository 中進(jìn)行構(gòu)建，WHERE ... 操作在 BookApplication 中進(jìn)行構(gòu)建，最后的 F5 執(zhí)行也在 BookApplication 中。

從上面的代碼中，我們可以看到，IQueryable 很好的解決了使用 IEnumerable 所出現(xiàn)的問(wèn)題，一個(gè)查詢(xún)可以應(yīng)對(duì)千變?nèi)f化的應(yīng)用查詢(xún)，IQueryable 看起來(lái)好像是那么的強(qiáng)大，其實(shí) IQueryable 的強(qiáng)大并不限于此，上面說(shuō)的是查詢(xún)表達(dá)式，那添加、修改和刪除操作，可以使用它進(jìn)行完成嗎？修改和刪除是可以的，添加并不能，具體可以參考 dudu 的這篇博文：開(kāi)發(fā)筆記：基于EntityFramework.Extended用EF實(shí)現(xiàn)指定字段的更新。

關(guān)于 EntityFramework.Extended 的擴(kuò)展，需要記錄下，因?yàn)檫@個(gè)東西確實(shí)非常好，改變了我們之前的很多寫(xiě)法和問(wèn)題，比如，在之前使用 EF 進(jìn)行修改和刪除實(shí)體，我們一般會(huì)這些寫(xiě)：

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();} }

上面的寫(xiě)法有什么問(wèn)題呢？其實(shí)最大的問(wèn)題就是，我們要進(jìn)行修改和刪除，必須先獲取這個(gè)實(shí)體，也就是先查詢(xún)?cè)龠M(jìn)行修改和刪除，這個(gè)就有點(diǎn)多余了，尤其是 UpdateNameByIds 中的批量修改，先獲取 Book 對(duì)象列表，然后再遍歷修改，最后保存，是不是有點(diǎn) XXX 的感覺(jué)呢，仔細(xì)想想，還不如不用 EF 來(lái)的簡(jiǎn)單，因?yàn)橐粋€(gè) Update SQL 就可以搞定，簡(jiǎn)單并且性能又高，為什么還要使用 EF 呢？這是一個(gè)坑？其實(shí)使用 EF 也可以執(zhí)行 SQL，但這就像換了個(gè)馬甲，沒(méi)有什么卵用。

針對(duì)上面的問(wèn)題，該如何解決呢？很簡(jiǎn)單，使用 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>();} }

有沒(méi)有發(fā)現(xiàn)什么不同呢？原來(lái) IQueryable 還可以這樣寫(xiě)？這貨居然不只是用于查詢(xún)，也可以用于刪除和修改，另外，通過(guò)追蹤生成的 SQL 代碼，你會(huì)發(fā)現(xiàn)，沒(méi)有了 SELECT，和我們直接寫(xiě) SQL 是一樣的效果，在執(zhí)行修改和刪除之前，我們需要對(duì)查詢(xún)表達(dá)樹(shù)進(jìn)行過(guò)濾，也就是說(shuō)的，當(dāng)我們最后應(yīng)用修改的時(shí)候，會(huì)是在這個(gè)過(guò)濾的查詢(xún)表達(dá)樹(shù)基礎(chǔ)上的，比如上面的 Delete 操作，我們先通過(guò) bookId 進(jìn)行過(guò)濾，然后直接進(jìn)行 Delete 就可以了，哇塞，原來(lái)是這樣的簡(jiǎn)單。

當(dāng) BookApplication 操作變的簡(jiǎn)單的時(shí)候，BookRepository 也會(huì)相應(yīng)變的簡(jiǎn)單：

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

一個(gè) IQueryable 表達(dá)樹(shù)，一個(gè) SaveChanges 操作，就可以滿(mǎn)足 BookApplication 中的所有操作。

---

既然 IQueryable 是這么的強(qiáng)大，那用它就好了，為什么還要討論呢？如果你 Google 搜索“Repository IQueryable”關(guān)鍵詞，會(huì)發(fā)現(xiàn)大量的相關(guān)文章，我先貼出幾個(gè)非常贊的討論：

• 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（簡(jiǎn)潔而有力）
• Why the Repository Pattern Is Still Valid

上面只是部分，關(guān)于這類(lèi)的文章，老外寫(xiě)的非常多，而且評(píng)論中的討論也非常激烈，因?yàn)橛⒄Z(yǔ)實(shí)在差，我大概看了一些，出乎我意料之外的是，很多人都不贊成 Repository 返回 IQueryable，但討論的卻非常有意思，比如有個(gè)老外這樣感嘆：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 是一個(gè)壞主意，但至少我更了解他們的反對(duì)理由，是不是很有意思呢？

關(guān)于 Repository 返回 IQueryable 的討論，我大致總結(jié)下：

好處：

延遲執(zhí)行。

減少 Repository 重復(fù)代碼（GetBy...）。

IQueryable 提供更好的靈活性。

...

壞處：

隔離單元測(cè)試。

數(shù)據(jù)訪(fǎng)問(wèn)在 Repository 之外完成。

數(shù)據(jù)訪(fǎng)問(wèn)異常在 Repository 之外拋出。

該領(lǐng)域?qū)訉⒊涑庵@些相當(dāng)詳細(xì)查詢(xún)。

...

好處就不多說(shuō)了，因?yàn)槲覀兩厦嬉呀?jīng)實(shí)踐過(guò)了，關(guān)于壞處，“隔離單元測(cè)試”是什么意思呢？也就是說(shuō)我們不能很好的對(duì) Repository 進(jìn)行單元測(cè)試，一方面是因?yàn)?IRepository 是那么的簡(jiǎn)單（就兩個(gè)方法），另一方面 IQueryable 是查詢(xún)表達(dá)樹(shù)，它并不是完成時(shí)，只有在具體調(diào)用的時(shí)候才會(huì)查詢(xún)完成，所以，對(duì)于 Repository 的單元測(cè)試，顯然是沒(méi)有任何意義的。

關(guān)于 Repository Pattern and IQueryable 這篇博文，我想再說(shuō)一下，因?yàn)檫@個(gè)老外的觀(guān)點(diǎn)非常贊，首先，它是基于 Repository 模式概念基礎(chǔ)上說(shuō)的，所以，我們一開(kāi)始說(shuō)：在“偽 DDD”設(shè)計(jì)中，你可以把 Repository 看作是數(shù)據(jù)訪(fǎng)問(wèn)層。這是兩個(gè)不同的前提，我再大致總結(jié)下這個(gè)老外的觀(guān)點(diǎn)：

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

看了上面，是不是有點(diǎn)豁然開(kāi)朗的感覺(jué)呢，其實(shí)從 Repository 的模式概念方面考慮，使用 IQueryable 確實(shí)不是很恰當(dāng)，但不可否認(rèn)的是，IQueryable 又這么強(qiáng)大和便利，怎么辦呢？就像博文一開(kāi)始強(qiáng)調(diào)的那樣：Repository 的概念就不多說(shuō)了，在“偽 DDD”設(shè)計(jì)中，你可以把它看作是數(shù)據(jù)訪(fǎng)問(wèn)層。

所以呢，如果你的項(xiàng)目是“偽 DDD”，并且 Repository 是被你看作“數(shù)據(jù)訪(fǎng)問(wèn)層”，那么使用 IQueryable 就沒(méi)啥問(wèn)題了。

轉(zhuǎn)載于:https://www.cnblogs.com/xishuai/p/repository-return-iqueryable-or-ienumerable.html

總結(jié)

以上是生活随笔為你收集整理的Repository 返回 IQueryable？还是 IEnumerable？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。