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

odopli94  于 2022-12-24  发布在  .NET
关注(0)|答案(2)|浏览(242)

有人能解释一下什么时候应该从ODataControllerApiController继承控制器吗?
这个问题是由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属性进行开箱即用的工作,但是前面提到的不一致让我觉得我做错了什么。

bqf10yzr

bqf10yzr1#

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

相关问题