asp.net-mvc - 通过 OData 和 WebAPI 公开大数据模型

Question

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

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

所以我的问题:

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

(当我生成我的 EF 模型时，可能构建所有 WebAPI 代码的 T4 模板？？)

是否有任何令人信服的理由考虑使用 WebAPI 与 WCF-DS 来公开大型 URI 域？

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

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

谢谢。

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

Answer 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 协议(protocol)公开数据库记录更新操作之前三思而后行，但这种方法没有任何技术问题。