通过 OData 和 WebAPI 公开大数据模型答案

【问题标题】：Exposing Large Data Models via OData and WebAPI通过 OData 和 WebAPI 公开大数据模型
【发布时间】：2014-07-25 16:13:56
【问题描述】：

我有一个包含大约 200 个表的 EF 模型，其中 75 个我想通过 REST 在 MVC 应用程序中公开。我首先添加了一个 WCF 数据服务 (WCF-DS)，将其指向 EF 上下文，然后，我在大约 2 分钟内将整个数据库映射到具有完整 OData 语法支持的 REST URI。

接下来我尝试使用 WebAPI 创建相同的 REST URI 空间。当我尝试添加 WebAPI OData 控制器时，它要求的第一件事是模型类，当我完成创建控制器（并将所有必需的 ODataConventionModelBuilder 代码复制到 WebApiConfig 中）时，我只有一个 REST 端点！我现在的印象是，WebAPI 不太适合用大量蛮力公开整个 EF 模型。

所以我的问题：

我是否错过了一种一举将一组 WebAPI 端点映射到 EF 模型的方法？

（可能是 T4 模板在我生成我的 EF 模型时构建所有 WebAPI 代码？？）
是否有任何令人信服的理由考虑使用 WebAPI 与 WCF-DS 来公开大型 URI 域？

（有人说 WebAPI 的好处是可以对每个 MVC/HTTP 请求进行细粒度控制，但如果目标是符合 OData 规范，这似乎适得其反。我不确定我是否想要有 75 个控制器和 1000 行代码，它们会诱使我的开发同事改变一个实体的行为，从而导致与其他实体不同的行为。）

（对于诸如安全、缓存或性能限制等横切关注点，WCF-DS 似乎对 Interceptors 及其 DataServiceConfiguration 类具有足够的配置能力。WebAPI 的任何功能在这方面会做得更好吗？）

谢谢。

更新：我发现 Julie Lermon 的这篇文章有点帮助：http://msdn.microsoft.com/en-us/magazine/dn201742.aspx

【问题讨论】：

由于 WCF DS 已停止使用，因此这个问题更加相关。我正在考虑编写自己的 T4 模板来模仿 web api odata 教程，这些教程似乎希望用户手动为每个模型创建一个 api 控制器。我们的数据库还有 200 多张表！

标签： asp.net-mvc entity-framework asp.net-web-api wcf-data-services

【解决方案1】：

由于我只使用 WCF DS 公开了 EF 模型，因此我无法评论 Web API 问题。但是我们从来没有真正的理由用我们的模型的 Web API 替换 WCF DS，因为您也注意到，EF 和 WCF DS 可以很好地结合在一起，您基本上可以免费获得 OData 提要。在客户端，情况有所不同：我们从 WCF 数据服务客户端开始，它试图模仿 Linq to Entity Framework，但有很多限制，以至于我最终编写了自己的 OData 客户端（你可以阅读让我们不满意的原因使用 WCF DS 客户端部分 here)。

回到服务器端：我们的域很大，我们有 80 多个表，几乎 1000 列。我们甚至支持使用批量更新（事务的 OData 模拟）的所有 CRUD 操作。虽然由于设计原则，我建议在通过 OData 协议公开数据库记录更新操作之前三思而后行，但这种方法没有任何技术问题。

【讨论】：

感谢@Vagif，很高兴听到一些确认您已经使用 WCF 取得了成功。我认为我们将朝着这个方向前进，看看情况如何。

【解决方案2】：

我认为 Web API + OData 扩展对于大多数或用例来说被高估了，我的论点是 OData 从根本上是面向数据的，而 Web API 已经成为非常适合通用 API，其中包括面向服务的 API。

我相信，您的用例是非常面向数据的层的主要示例，因为您似乎不想在该层（此 HTTP API 的服务器端）上添加太多域逻辑。 WCF-DS 非常适合这一点，特别是如果您只是包装一个为您完成 90% 工作的 EF 模型（正如您已经观察到的那样）。

当然，如果您在该层（在该层）建模更复杂的流程，那将是另一回事，因此像您一样探索这两个选项始终是一个非常好的主意。通常，显而易见的选择应该是自然而然的，要么您将使用 Web API 编写大量冗余代码（与 WCF-DS 一起使用），要么您将通过玩奇怪的实体而不是与 WCF-DS 非常严格的框架作斗争，而不是-非常 RESTful 的 OData 操作（单独使用 Web API）。

具有 OData 扩展的 Web API 处于中间位置，尽管与自定义 WCF-DS 提供程序相比，它提供哪些优势并不总是很清楚。我想这对于已经了解 Web API 或 ASP.NET MVC 的人来说很好，如果你想要开源，这可能是一个要求。我个人不会用技术论据来讨论这项技术，除了人们应该知道的几个陷阱（但与它的设计无关）。 I've ranted about all of this a while ago，如果你想要更多，但我再次强调，在任何这些中都没有硬道理——讨论架构和设计是一个非常重要的意见问题。

更新： WCF-DS was killed.

【讨论】：