Repository 返回 IQueryable？还是 IEnumerable？代码片段

CodeSnippet.Cn
代码片段

Repository 返回 IQueryable？还是 IEnumerable？

.NetCore 小笨蛋发布于：2022年06月22日更新于：2022年06月27日 110

这是一个很有意思的问题，我们一步一步来探讨，首先需要明确两个概念（来自 MSDN）：

- IQueryable：提供对未指定数据类型的特定数据源的查询进行计算的功能。
- IEnumerable：公开枚举数，该枚举数支持在非泛型集合上进行简单迭代。

IQueryable 继承自 IEnumerable，它们俩最大的区别是，IQueryable 是表达式树处理，可以延迟查询，而 IEnumerable 只能查询在本地内存中，Repository 的概念就不多说了，在“伪 DDD”设计中，你可以把它看作是数据访问层。

下面我们先实现 Repository 返回 IEnumerable：

```csharp
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 会是怎样的呢？我们看下代码：

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

只有一个 GetBooks 查询，那它能满足各类查询需求吗？我们看下 Application 中调用的代码：

```csharp
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实现指定字段的更新。](http://www.cnblogs.com/dudu/p/4735211.html "基于EntityFramework.Extended用EF实现指定字段的更新。")

关于 EntityFramework.Extended 的扩展，需要记录下，因为这个东西确实非常好，改变了我们之前的很多写法和问题，比如，在之前使用 EF 进行修改和删除实体，我们一般会这样写：

```csharp
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 就可以，我们改造下上面的代码：

```csharp
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 也会相应变的简单：

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

一个 IQueryable 表达树，一个 SaveChanges 操作，就可以满足 BookApplication 中的所有操作。

关于 Repository 返回 IQueryable 的讨论，网上的文章大致总结如下：

好处：

- 延迟执行。
- 减少 Repository 重复代码（GetBy...）。
- IQueryable 提供更好的灵活性。
...

坏处：

- 隔离单元测试。
- 数据访问在 Repository 之外完成。
- 数据访问异常在 Repository 之外抛出。
- 该领域层将充斥着这些相当详细查询。
- ...

好处就不多说了，因为我们上面已经实践过了，关于坏处，“隔离单元测试”是什么意思呢？也就是说我们不能很好的对 Repository 进行单元测试，一方面是因为 IRepository 是那么的简单（就两个方法），另一方面 IQueryable 是查询表达树，它并不是完成时，只有在具体调用的时候才会查询完成，所以，对于 Repository 的单元测试，显然是没有任何意义的。

这里⇓感觉得写点什么，要不显得有点空，但还没想好写什么... 返回顶部