公开 DTO 时的 ApiController 与 ODataController

Question

谁能解释我什么时候应该继承我的控制器表单ODataController vs ApiController？

问题是因为ApiController返回的结果可以用OData查询过滤。

如果我将QueraybleAttribute 应用于控制器的方法，即使操作返回IEnumerable，也会处理查询。
但是，如果没有此属性但调用 config.EnableQuerySupport()，则仅当方法返回 IQueryable 时才会处理查询。
我认为这不是一致的行为。 WebAPI documentation and examples 暗示控制器必须从 ODataController 中初始化。我有点困惑。
ApiControlleraccidentally 和部分支持 OData 协议的一部分（至少 $skip、$filter 和 $top）。或者这是设计使然，我需要 ODataController 来获得完整的 ODataSupport。

真正的问题是我的服务公开了 DTO，而不是 POCO。可能没有一对一的映射。需要将针对 DTO 的 OData 查询转换为针对 POCO 的 EF 查询。
现在只是玩 OData。我检索实体并将它们转换为 DTO。诚然，对于每个请求从数据库中获取所有这些请求的性能并不是很好，但对于实验却是可以容忍的。但是，如果它需要一些过滤的 DTO 子集，则绝对不需要将所有实体返回给客户端。
OData 查询开始使用 ApiController 和 Querayble 属性开箱即用，但前面提到的不一致让我觉得我做错了。

Answer 1

这很好地解释了这些差异： http://blogs.msdn.com/b/alexj/archive/2012/08/15/odata-support-in-asp-net-web-api.aspx

Answer 2

谁能解释我什么时候应该继承我的控制器表单 ODataController 与 ApiController？

如果您想公开一个遵循OData protocol 的端点，您可能想从ODataController 继承。如果您想做其他事情，例如 REST 端点，请从 ApiController 继承。

应用 WebAPI OData 框架的某些部分而不应用其他部分可能不是一个好主意。在某些情况下它可能会起作用，但在其他情况下可能效果不佳。例如，您可能会获得查询支持，但可能不会生成 $metadata 端点（这只是推测，实际症状可能不同）。

听起来您已经在使用 EntityFramework。我知道有许多示例展示了如何将其公开为 OData 端点。

如果您出于某种原因不想这样做，您可以自己实现查询。这在this tutorial 的几个地方有简要介绍，但要点是在您的操作中添加ODataQueryOptions<T> 类型的参数，并使用其上的方法来过滤您的结果集。但是，为所有可能的 OData 查询生成良好的数据库查询可能会很痛苦，因此您应该尽可能避免这种情况。