暴露DTO时ApiController与ODataController的对比

Question

有人能告诉我什么时候我应该从ODataController和ApiController继承我的控制器吗？

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

如果我对contoller的方法应用QueraybleAttribute，那么即使操作返回IEnumerable，查询也会被处理。

但是，如果没有此属性，但使用了调用config.EnableQuerySupport()，则只有在方法返回IQueryable时才会处理查询。

我认为这不是一致的行为。WebAPI documentation and examples暗示控制器必须从ODataController递增。我有点困惑。

ApiController accidentally和部分支持OData协议的一部分(至少是$skip、$filter和$top)。或者这是设计，我需要完整的ODataSupport的ODataController。

真正的问题是我的服务公开的是DTO，而不是POCOs。可能没有一对一的映射。需要将针对DTO的OData查询转换为针对POCOs的EF查询。

现在就玩OData吧。我检索实体并将它们转换为DTO。诚然，这并不是很好的性能，因为每个请求都要从DB中获取，但对于实验来说却是容忍的。但是，如果客户端需要一些经过过滤的DTO子集，则绝对不需要将所有实体返回给客户端。

OData查询开始使用ApiController和Querayble属性，但是前面提到的不一致让我做错了事情。

Answer 1

有人能解释一下我什么时候应该从ODataController vs ApiController继承我的控制器吗？

如果要公开符合OData protocol的终结点，则需要从ODataController继承。如果您想做一些其他的事情，比如REST端点，那么从ApiController继承。

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

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

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

Answer 2

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