为了账号安全,请及时绑定邮箱和手机立即绑定

要返回IQueryable <T>还是不返回IQueryable <T>

要返回IQueryable <T>还是不返回IQueryable <T>

HUH函数 2019-12-10 10:37:22
我有一个存储库类,将我的LINQ包装到SQL数据上下文中。存储库类是业务线类,其中包含所有数据层逻辑(以及缓存等)。这是我的repo界面的v1。public interface ILocationRepository{    IList<Location> FindAll();    IList<Location> FindForState(State state);    IList<Location> FindForPostCode(string postCode);}但是为了处理FindAll的分页,我正在辩论是否公开IQueryable <ILocation>而不是IList来简化诸如分页之类的接口。从数据存储库中暴露IQueryable的利弊是什么?很感谢任何形式的帮助。
查看完整描述

3 回答

?
慕村225694

TA贡献1880条经验 获得超4个赞

优点;可组合性:

  • 来电者可以添加过滤器

  • 呼叫者可以添加分页

  • 来电者可以添加排序

  • 等等

缺点 不可测试性:

  • 您的存储库不再可以进行单元测试。您不能依靠:a:它起作用,b:它做什么

    • 调用者可以添加一个不可翻译的函数(即没有TSQL映射;在运行时中断)

    • 呼叫者可以添加一个过滤器/排序,使其像狗一样执行

  • 由于调用者期望IQueryable<T>是可组合的,因此它排除了不可组合的实现-或迫使您为其编写自己的查询提供程序

  • 这意味着您无法优化/分析DAL

为了稳定起见,我考虑公开资料库IQueryable<T>公开Expression<...>资料库。这意味着我知道存储库的行为方式,并且我的上层可以使用模拟,而不必担心“实际的存储库是否支持此操作?” (强制进行集成测试)。

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


查看完整回答
反对 回复 2019-12-10
  • 3 回答
  • 0 关注
  • 954 浏览

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信