编写自定义 OData uri 解析器或自定义 IQueryable 提供程序哪个更容易？
我想要创建一个从多个源返回数据的 OData 服务。因此，我无法将 WCF 数据服务与任何现成的提供程序一起使用，而且我们确实希望对数据模型有更多控制。
我发现如果我们坚持使用 MS 产品堆栈，我们有两个选择：
使用 WCF 和 WebGet/WebInvoke 来模拟 OData api，并在内部执行查询字符串解析和翻译。例如，对于数据位于 Sql 数据库中的情况，我们必须将 $filter 子句转换为 SQL where 子句才能构建查询。请注意，我们不能使用任何类型的 ORM，因为我们的数据模型是动态的，并且我们没有任何可以用 ORM 填充的 CLR 实体类。
我们将 WCF 数据服务与自定义提供程序一起使用，这要求我们为资源集传递 IQueryable，这使我们要么执行 Select * FROM Table 并使用 Linq to 对象，要么实现我们自己的 IQueryable 提供程序，该提供程序支持OData 所需的表达式。 WCF 数据服务是否接受 IQuerable？
哪一个最容易实施？我们主要只想支持 OData 规范的 $filter 功能，$expand 和 $select 可以稍后提供。
放弃 WCF 数据服务似乎很可惜，如果它可以提供解析的 OData 查询，然后您可以自己将其转换为 Linq 查询，而不是期望您的数据源具有 IQueryable 提供程序，那就更好了。
I'm wanting to create an OData service that returns data from multiple sources. For this reason I cannot use WCF Data Services with any of the out-of-box providers, plus we really want more control over the data model.
I see we have two options if we stick with the MS product stack;
Use WCF with WebGet/WebInvoke to mimic an OData api, and perform the query string parsing and translation internally. e.g. For cases where our data is in a Sql database we must translate the $filter clause into a SQL where clause in order to build our query. Note here that we cannot use any kind of ORM here, since our Data model is dynamic and we don't have any CLR entity classes that could be populated with an ORM.
We use WCF Data Services with a Custom provider, this requires us to pass an IQueryable for the resource set, which leaves us with either doing a Select * FROM Table and using Linq to objects, or implementing our own IQueryable provider that supports the expressions required by OData. Will WCF Data Services even accept an IQuerable?
Which would be the easiest to implement? We mostly only want to support the $filter features of the OData spec, $expand and $select can come later.
It seems a shame to abandon WCF Data Services, it would be preferable if it could supply the parsed OData query that you could then translate to a Linq query yourself, rather than expecting your data source to have an IQueryable provider.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以编写自己的数据上下文类。您需要的功能越多，付出的努力就越大。 WCF 数据服务工具包可能会有所帮助，我发现这个OData 路线图：将任何数据源公开为 OData 服务 来自 MIX 的演示文稿会很有帮助。
所以我说编写一个自定义的 IQueryable 提供程序会更容易、更简洁。
You can write your own data context class. The more functionality you need the greater the effort. The WCF Data Services Toolkit may be of some help and I found this OData Roadmap: Exposing Any Data Source as an OData service presentation from MIX to be helpful.
So I say writing a custom IQueryable provider would be both easier and cleaner.