我有一个约有200个表的EF模型，其中75个我希望通过REST在MVC应用程序中公开。我首先添加了一个WCF数据服务（WCF-DS），将其指向EF上下文，然后bam，我将整个数据库映射到REST URI，并在大约2分钟内完成OData语法支持。
接下来，我尝试使用WebAPI创建相同的REST URI空间。当我尝试添加一个WebAPI OData Controller时，它首先要求的是一个Model Class，当我完成创建控制器（并将所有必需的ODataConventionModelBuilder代码复制到WebApiConfig中）时，我只有一个REST端点！我现在的印象是，WebAPI并不适合用很多暴力来暴露整个EF模型。
所以我的问题：
我是否错过了将一堆WebAPI端点一次性映射到EF模型的方法？
（也许在我生成EF模型时构建所有WebAPI代码的T4模板？）
是否有任何令人信服的理由考虑使用WebAPI与WCF-DS来公开大型URI域？
（有人说WebAPI的好处是对每个MVC / HTTP请求进行细粒度控制，但如果目标是符合OData规范，这似乎适得其反。我不确定我是否想要拥有75个控制器和1000个代码行，可以诱使我的开发人员改变一个实体的行为，从而导致其他实体的行为不同。）
（对于交叉问题，例如安全性，缓存或性能限制，WCF-DS似乎具有足够的配置能力，可以使用拦截器及其DataServiceConfiguration类。是否有任何WebAPI功能可以在这里做得更好？）
感谢。
更新：我发现Julie Lermon的这篇文章有点帮助：http://msdn.microsoft.com/en-us/magazine/dn201742.aspx
答案 0 :(得分：1)
由于我只使用WCF DS公开了EF模型，因此无法对Web API问题发表评论。但是我们从来没有真正有理由用我们的模型用Web API替换WCF DS，因为正如你也注意到的那样，EF和WCF DS一起玩的很好，你基本上可以免费获得OData源。在客户端，情况有所不同：我们开始尝试模仿Linq到实体框架的WCF数据服务客户端，但是有很多限制，我最终编写了自己的OData客户端（你可以读到是什么让我们感到不快使用WCF DS客户端部分here）。
回到服务器端：我们的域很大，我们有80多个表，有近1000列。我们甚至使用批量更新（OData模拟事务）支持所有CRUD操作。虽然由于设计原则，我建议在通过OData协议公开数据库记录更新操作之前三思而后行，但我们对此方法没有任何技术问题。
答案 1 :(得分：1)
我认为Web API + OData扩展对于大多数或用例来说都被高估了，我的论点是OData基本上是面向数据的，而Web API已经成为非常适合通用API，包括面向服务的 API。
我认为，您的用例是一个面向数据的层的主要示例，因为您似乎不希望在此层（此HTTP API的服务器端）上添加太多域逻辑。而且WCF-DS非常适用于此，特别是如果你只是包装一个为你做90％工作的EF模型（正如你已经观察到的那样）。
当然，如果 在该层（在该层）中建模更复杂的流程，那将是一个不同的故事，所以像你一样探索这两个选项总是一个非常好的主意。通常情况下，显而易见的选择应该是自然而然的，要么您将使用Web API编写大量冗余代码（使用WCF-DS），要么您将通过使用奇数实体来解决WCF-DS非常严格的框架而不是 - 非常RESTful的OData操作（仅使用Web API）。
Web API及其OData扩展位于中间位置，但并不总是清楚它提供的优于自定义WCF-DS提供程序的优势。我想这对于已经了解Web API或ASP.NET MVC的人来说很好，如果你想要开源，可能是一个要求。我个人不会用技术论证来讨论这项技术，除了少数人应该知道的问题（但与其设计无关）。 I've ranted about all of this a while ago，如果你想要更多，但我再次强调，任何一个都没有硬性事实 - 讨论建筑和设计在意见问题上是非常重要的。
更新： WCF-DS was killed。