0

我们正在为具有以下要求的客户构建查询服务：

  • 支持 Where、Begin、Contains、And、Or、Paging、Select。（1-主要）
  • 查找/映射多个值从一个值到另一个值。客户端将传递数百个值，并将返回相同数量的值。(2)
  • 为无效请求返回一些明确的错误代码（缺少参数、指定的未知字段、指定的未知条件等）（3）

对于(1)和(2)，我们已经看到OData具有强大的语法来支持它们，并且(OData + WebAPI)可能是一个好的/灵活的解决方案，但我们有一些担忧：

  • 由于来自(2)的过滤器大小很大，客户端希望通过POST而不是GET传递查询。我们看到了一些选项，因此我们考虑了以下两种 OData 解决方案：（$batch-supported OData endpoint，POST OData URI并手动将其解析为ODataQueryOption）
  • OData 端点查询性能存在一些问题。它足够好还是我们可以只使用POST OData URI并使用自定义存储过程以获得最佳性能？
  • 对于(3)，我们似乎还没有找到调用 OData 端点以返回正确错误代码的方法。

我们还考虑构建一个自定义 JSON 对象，与ODataQueryOption几乎相同，并针对每个需求使用 Web.API 操作，以防 OData 无法以良好的性能完全处理这些需求。但这将是我们最后的选择。

那么您选择实现上述 3 项的选择是什么？谢谢。

4

1 回答 1

0

我将首先研究OData 批处理以确定它是否足够。这样您就不需要为您的第二个需求重新实现任何低级别（这将是您的第一个解决方案）。

查询性能通常与后端一样好，此时不应考虑解析 URI。如果您使用的是实体框架，请查看 Linq 查询的外观，以及它们最终如何转换为真正的后端。

此处指定了错误报告。请注意，您将能够在 OData 4.0 的同一响应中返回多个错误。您有多种方法可以使用 ASP.NET Web API + OData 扩展创建此类响应。查看ODataErrors和CreateODataErrorResponse。

我认为您的第一个要求已完全满足。

最终，您将不得不凭直觉行事，或者，如果您有足够的时间进行技术评估，请使用一些原型并运行一些实际数字。

于 2013-10-04T16:54:20.673 回答