3

我有一个连接到实体框架以公开 DataServices 的 OData 端点，但我想在运行时根据一些元数据来塑造出来的数据，以使查询比 URL 更具限制性

例如：

http://services.odata.org/OData/OData.svc/Category(1)/Products ?$top=2&$orderby=name

如果这是位于欧洲的用户，我希望它返回具有“欧洲”区域的产品，但我宁愿 url 不必具有客户端提供的过滤器，例如：

http://services.odata.org/OData/OData.svc/Category(1)/Products $top=2&$orderby=name&$filter=Region eq 'Europe'

我发现查询拦截器可以用于这类事情，但它是一个适用于大量实体的所有查询的概念，所以我希望有一种更通用的方法将它应用于所有实体，而不是必须在每个实体上指定一个拦截器。

我还在考虑根据用户权限隐藏某些字段，例如，如果某个字段被标记为敏感，我可以根据是否允许用户查看敏感数据从查询或结果中动态删除该字段。我认为我上面描述的技术将是这两种情况的解决方案。

修改 url 可能会被命中和错过所以也许我可以访问表达式树 EF 创建并在它执行之前从中添加或删除项目？

以防万一它是相关的，我使用 DataService 基类来公开数据：

公共类 MyDataService : 数据服务

这既快速又简单，但可能难以实现我想要的

非常感谢任何帮助-即使它只是我要实现的目标的特定名称，也将有助于研究解决方案

4

1 回答 1

2

不幸的是，今天在 WCF 数据服务中没有一种简单的方法可以做到这一点（正如您提到的 QueryInterceptors 除外）。团队经常听到对此类功能的要求，我们正在这方面进行一些改进，但目前还不能公开承诺任何事情。

可以使用自定义提供程序接口 (IDataServiceMetadata/QueryProvider) 来完全自定义 WCF DS 所做的大部分工作，但是通过 EF 执行此操作需要大量工作，并且可能无法做到完美。同样，该团队正在寻找使自定义 EF 提供程序更容易的方法（例如公开我们对这些接口的内置实现），但我再次无法确定何时可用。

ASP.NET Web API是创建 OData 服务的另一种选择，具有更大的灵活性，尽管您可能需要编写比使用 EF + DataService 更多的代码。

于 2013-02-05T22:31:39.780 回答