在没有实体框架的情况下构建 OData API答案

【问题标题】：Build OData API without Entity Framework在没有实体框架的情况下构建 OData API
【发布时间】：2016-01-03 11:30:44
【问题描述】：

我有一个现有的 Web 表单项目，它由 3 个不同的项目组成：UI 层（Web 项目）、业务逻辑层和数据库项目。我已经编写了连接数据库并将数据返回给业务逻辑层的数据访问方法。

现在我们需要提供一个 REST API，我正在考虑将 oData API 与 REST 一起使用。但是我看到的所有例子都使用实体框架，我就是不能使用实体框架，因为我们的数据访问层将数据返回给业务层，然后业务层处理该数据并添加一些逻辑，然后将其呈现给 UI 层。

我还能使用 oData API 吗？如果是，那么我是否需要为 oData API 的每个复杂查询手动创建新方法？ OData API 将如何访问我的 BL 层？

【问题讨论】：

【解决方案1】：

你可以做到这一点（我自己也做过类似的），但这是非常艰苦的工作。

对我来说，OData 总是感觉像是一种通过 Web 服务公开实体框架的方式，因此如果您尝试在没有实体框架的情况下实现它，您最终将花费大量时间来解析对数据访问层的查询。

如果您决定走这条路，或许可以考虑只实施 OData 规范的一部分 - 找出您真正希望能够使用的部分 - 因为它是巨大的并且任务艰巨。

这些只是根据我的经验，您可能拥有比我刚开始时更好的数据访问层 API 设置，这可以使事情变得更加容易。

编辑回答最后一个问题：

您是否需要为 oData API 的每个复杂查询手动创建新方法？这实际上取决于您的数据将如何公开以及您的数据访问层是如何设置的。

【讨论】：

感谢 Tom，但是当 OData 迫使您使用实体框架时，为什么会有如此多的讨论呢？当我不能使用我的 DAL 层代码时，OData 对我来说毫无用处，考虑到围绕它的炒作，这在某种程度上是没有意义的。
炒作是因为它为您提供了很多作为消费者的东西。它不会强迫您使用实体框架，但使用实体框架真的很容易。我已经成功实现了很多没有实体框架的 OData，但这并不容易。这实际上只是一个警告，请确保您确实想要使用 OData，并且在开始之前它确实会为您带来好处！
大家好！目前，我面临着与您类似的问题，我有一个 BFF（OData），它消耗一堆也基于 OData（使用 ODataClients）的 API。我们需要从 API 中删除 OData 并将其保留在 BFF 端，但我们不能错过 Expand、Select 等一些功能......所以我想知道有一种方法可以基于一堆 API 而不是 Data 创建 ODataContext根据？谢谢！