我再次审查 OData，因为我想在 EF 的新 Rest 项目中使用它，但我也有与几年前相同的担忧。
公开通用的 IQueryable 可能非常危险。限制潜在昂贵的查询必须在其他地方完成。DB，连接级别。
OData 不允许开发人员对行为进行任何拦截/自定义，因为它位于界面之外。
一般来说，OData 与 DI 配合得不好。虽然可以 DI 替代 IQueryable，但您无法拦截 OD 调用并检查、修改或修改。
我的建议是将该工具分解为更多不同的元素，以允许更大的定制和重用。打破黑匣子:)在单一责任方面也会更好。是否有可能有执行以下操作的组件
来自 url 的表达式生成器。将 OData url 扩展转换为可与 IQueryable 一起使用但独立于 IQueryable 的类型化表达式。例如，为 where 生成 T => Expression<Func<T, bool>> 。这将是一个超级有用的独立组件，并支持作为标准更广泛使用的 OData url 格式。
用于将表达式附加到 EF 上下文的 EF 适配器。一个 EF 适配器，用于将表达式附加到 EF 上下文或在任何其他 DI 代码中使用。因此，服务可以封装接口并获得 OData 功能的优势，而不是公开公共 IQueryable。其余获取 -> 表达式生成 -> 映射到 IQueryable。
这种方法将允许开发人员拦截查询调用并根据需要自定义行为，同时保持简单情况的易用性。我们可以将 OData 和 EF 嵌入到存储库模式中，在其中添加我们自己的功能。