我有一个存储库类,将我的LINQ包装到SQL数据上下文中。存储库类是业务线类,其中包含所有数据层逻辑(以及缓存等)。
这是我的repo界面的v1。
public interface ILocationRepository { IList<Location> FindAll(); IList<Location> FindForState(State state); IList<Location> FindForPostCode(string postCode); }
但是为了处理FindAll的分页,我正在辩论是否公开IQueryable 而不是IList来简化诸如分页之类的接口。
从数据存储库中暴露IQueryable的利弊是什么?
很感谢任何形式的帮助。
优点;可组合性:
缺点 不可测试性:
IQueryable<T>
为了稳定起见,我考虑 不 公开资料库IQueryable<T>或 不 公开Expression<...>资料库。这意味着我知道存储库的行为方式,并且我的上层可以使用模拟,而不必担心“实际的存储库是否支持此操作?” (强制进行集成测试)。
Expression<...>
我仍然使用IQueryable<T>等 内部 信息库- 但不下来的边界。我在这里对这个主题发表了更多想法。将分页参数放在存储库接口上同样容易。您甚至可以使用扩展方法(在接口上)添加 可选的 分页参数,以便具体类仅可以实现1种方法,但调用者可以使用2或3个重载。