业务逻辑层中的 AsQueryable() - 不好的做法？（我想是的，但是....）答案

【问题标题】：AsQueryable() in Business logic layer - bad practice? (I think so but....)业务逻辑层中的 AsQueryable() - 不好的做法？（我想是的，但是....）
【发布时间】：2013-02-13 02:46:48
【问题描述】：

比如说我有（伪代码）：

public IEnumerable<User> GetUsers(string name) 在我的实体框架的数据访问层中，目前它在返回之前执行.ToList()，从而确保我的业务逻辑层不会干扰我的数据访问层。

但是，我需要在我的业务逻辑层对此进行稍微不同的变体，例如我需要更少的数据（例如，只需用户 ID 或进一步过滤它）。

为了有一个高效的 DB 层，我需要另一种方法返回数据的子集（重载方法或其他方法）。

但是，我可以“作弊”并省略 ToList()，而我的业务逻辑层最后添加了 AsQueryable()。因此，我的业务逻辑层能够操作创建的底层 sql。

人们对业务逻辑层中的 AsQueryable() 有何看法？在我看来，这是对我的数据访问层的泄漏抽象，但它可能非常方便，也许因为它位于 LINQ 命名空间（而不是 EF 命名空间）中，所以使用起来并没有那么糟糕？

编辑

需要注意的一些有用的东西（以及反对省略 ToList() 的论点）是，如果调用它的代码以前依赖 ToList() 进行数据绑定，即避免错误“数据直接绑定到存储查询 (DbSet , DbQuery, DbSqlQuery) 不受支持。”你不会得到一个编译时错误，只是一个运行时错误。因此，您需要确保在 UI 层之前确实调用了 ToList()。

【问题讨论】：

我通常采用实体框架是我的数据层的规则——除此之外我没有单独的 DAL。我注意到StackOverflow agrees（尽管使用的是 Linq-to-SQL）！
你在使用存储库模式吗？
问得好，是的，我们正在使用存储库模式进行多租户过滤。
我想我应该再限定一下。 GetUsers 实际上也位于业务逻辑层中，由 WebAPI 控制器调用 - WebAPI 控制器需要更少的数据。
感谢 cmets - 好点。

标签： linq entity-framework n-tier-architecture asqueryable

【解决方案1】：

我个人会在我的数据访问层中添加第二个执行 ToList() 的方法并调用它。这样更整洁：

functionA()
{
    return myDB.entityA.AsQueryable();
}

functionB()
{
    return functionA().ToList();
}

您将来可能需要从其他地方调用相同的函数。把它放在一个地方。

【讨论】：