.net 公开DTO时ApiController与ODataController的比较

odopli94 于 2022-12-24 发布在 .NET

关注(0)|答案(2)|浏览(243)

有人能解释一下什么时候应该从ODataController和ApiController继承控制器吗？
这个问题是由ApiController返回的结果可以用OData查询过滤这一事实引起的。
如果我将QueryableAttribute应用于控制器的方法，那么即使action返回IEnumerable，查询也会被处理。
但是，如果没有此属性，但使用调用config.EnableQuerySupport()，则仅当方法返回IQueryable时才处理查询。
我认为这是不一致的行为。WebAPI documentation and examples暗示控制器必须继承自ODataController。我有点困惑。
ApiControlleraccidentally和部分支持部分（至少$skip，$filter和$top）的OData协议。或者这是由设计，我需要ODataController完整的ODataSupport。
真实的的问题是我的服务公开了DTO，而不是POCO。可能没有一对一的Map。需要将针对DTO的OData查询转换为针对POCO的EF查询。
现在我们来看看OData。我检索实体并将它们转换为DTO。诚然，对于每个请求来说，从DB中获取所有实体的性能并不高，但对于实验来说，这是可以接受的。但是，如果客户机需要一些经过过滤的DTO子集，那么就绝对没有必要将所有实体返回给客户机。
OData查询开始使用ApiController和Querayble属性进行开箱即用的工作，但是前面提到的不一致让我觉得我做错了什么。

.net

来源：https://stackoverflow.com/questions/18233059/apicontroller-vs-odatacontroller-when-exposing-dtos

2条答案

按热度按时间

bqf10yzr1#

有人能解释一下什么时候我应该从ODataController和ApiController继承我的控制器吗？
如果要公开附着于OData protocol的终结点，则需要从ODataController继承。如果要执行其他操作（如REST终结点），则需要从ApiController继承。
应用WebAPI OData框架的某些部分而不应用其他部分可能不是一个好主意。在某些情况下可能会这样，但在其他情况下可能不会很好地工作。例如，您可能会获得查询支持，但可能不会生成$metadata端点（这只是推测，实际症状可能不同）。
听起来你好像已经在使用EntityFramework了，我知道有很多示例展示了如何将其公开为OData端点。
如果你出于某种原因不想这么做，你可以自己实现查询。这在this tutorial的一些地方有简要的介绍，但要点是向你的操作添加一个ODataQueryOptions<T>类型的参数，并使用它的方法来过滤你的结果集。然而，为所有可能的OData查询生成好的数据库查询可能是痛苦的，所以你应该尽可能避免这样做。