当我应该继承我的控制器表单ODataController vs ApiController时，有人可以解释一下吗？
问题是由ApiController返回的结果可以使用OData查询过滤的。
如果我将QueraybleAttribute应用于控制器的方法，即使操作返回IEnumerable，也会处理查询。
但是，如果没有此属性但调用config.EnableQuerySupport()，则只有在方法返回IQueryable时才会处理查询
我认为这不是一致的行为。 WebAPI documentation and examples暗示控制器必须从ODataController中删除。我有点困惑。
ApiController accidentally和部分支持OData协议的部分（至少$ skip，$ filter和$ top）。或者这是设计的，我需要ODataController来完成ODataSupport。
真正的问题是我的服务暴露了DTO，而不是POCO。可能没有一对一的映射。需要将OData查询再次转换为DTO到针对POCO的EF查询
现在只玩OData。我检索实体并将它们转换为DTO。不可否认，对于每个请求而言，从数据库中获取所有这些数据并不是非常有效，但仍然可以容忍实验。但是，如果它需要一些过滤的DTO子集，则定义上不需要将所有实体返回给客户端。
OData查询开始使用ApiController和Querayble属性开箱即用，但前面提到的不一致使我做错了。
答案 0 :(得分：11)
当我继承我的控制器表单时，有人可以解释我 ODataController vs ApiController？
如果要公开符合OData protocol的端点，您可能希望继承ODataController。如果您想要执行其他操作（例如REST端点），则继承自ApiController。
应用WebAPI OData框架的某些部分而不是其他部分可能不是一个好主意。在某些情况下，它可能在其他情况下效果不佳。例如，您可能会获得查询支持，但可能无法生成$ metadata端点（这只是推测，实际症状可能不同）。
听起来你已经在使用EntityFramework了。我知道有很多样本显示如何将其公开为OData端点。
如果您因某些原因不想这样做，可以自己实施查询。在this tutorial的几个地方简要介绍了这一点，但要点是在操作中添加ODataQueryOptions<T>类型的参数，并使用其中的方法过滤结果集。但是，为所有可能的OData查询生成良好的数据库查询可能会很痛苦，所以如果可能的话应该避免这种情况。
答案 1 :(得分：4)