返回IQueryable 还是不返回IQueryable

返回IQueryable 还是不返回IQueryable

优点；可组合性：

• 来电者可以添加过滤器
• 呼叫者可以添加分页
• 来电者可以添加排序
• 等等

缺点 不可测试性：

• 您的存储库不再可以进行单元测试。您不能依靠：a：它起作用，b：它做 什么 ；
  • 调用者可以添加一个不可翻译的函数（即没有TSQL映射；在运行时中断）
  • 呼叫者可以添加一个过滤器/排序，使其像狗一样执行
• 由于调用者期望

  IQueryable<T>

  是可组合的，因此它排除了不可组合的实现-或迫使您为其编写自己的查询提供程序
• 这意味着您无法优化/分析DAL

为了稳定起见，我考虑 不 公开资料库

IQueryable<T>

或 不
公开

expression<...>

资料库。这意味着我知道存储库的行为方式，并且我的上层可以使用模拟，而不必担心“实际的存储库是否支持此 *** 作？”
（强制进行集成测试）。

我仍然使用

IQueryable<T>

等 内部 信息库-
但不下来的边界。我在这里对这个主题发表了更多想法。将分页参数放在存储库接口上同样容易。您甚至可以使用扩展方法（在接口上）添加 可选的
分页参数，以便具体类仅可以实现1种方法，但调用者可以使用2或3个重载。