WCF数据服务（OData）与ASP.NET Web API

我正在devise一个由RESTful服务和各种客户端（Silverlight，iOS，Windows Phone 7等）组成的分布式应用程序。 现在我决定使用哪种技术来实现我的服务，WCF数据服务（OData）或ASP.NET MVC 4中提供的新的ASP.NET Web API。

我已经在线观看了几个演示，现在我倾向于使用WCF数据服务，主要是因为URI中内置的过滤机制和本地超媒体function。 我能看到的唯一不足就是Atom Pub规范的详细程度，而不是POX。

在作出决定之前，有什么我应该了解的这两种技术？ 为什么有人会通过WCF数据服务selectASP.NET Web API？

Answer 1

这是一个主观的问题，所以这是一个主观的答案。 国际海事组织，WCF有简单的RESTful服务的开销太多。 另一方面，Web API是专门为RESTful服务devise的。

我在这方面与Dave Ward达成一致。 看看他的博客了解更多信息。

我长期以来一直反对在WebForms项目中从ASMX转移到WCF的压力，因为接受WCF的复杂性主要只是通过不太灵活的JSON序列化来奖励我。 相比之下，我已经开始将我的一些项目从ASMX转换为Web API，并且对Web API如何轻松取代ASMX感到满意。

我相信微软终于在ASMX的简单性和WCF的Web APIfunction之间find了一个很好的平衡点。

Answer 2

WebApi和WCF数据服务之间目前还有其他的主要区别，这是从来没有人会提到的。 我希望MS能拿出一篇比较好的文章。

我一直跟随OData一段时间，也WebApi。 我总是发现一些重要的区别。

首先，我不确定你的老板的意思是“MS支持WebApi”，意思是他们不支持OData？ 国际海事组织，他们支持两者，目前有一些最小的重叠。 Windows Azure数据市场使用OData，Azure表暴露他们的数据存储使用OData，SharePoint 2010允许OData查询其数据，而来自MS的其他产品也支持它，例如Excel PowerPivot。 当涉及到关系数据时，它是一个非常强大的查询框架。 而且由于它是RESTful，所以任何语言，框架，设备等都可以与它集成。

这里是我喜欢OData + WCF数据服务：

当通过Web查询数据时，OData + WCF数据服务最终允许客户端应用程序更具“performance力”。 之前，我们总是不得不使用ASMX或WCF来构build僵化的Web API，这些Web API不透明，只要UI需要稍微不同的东西，就需要不断更改。 客户端应用程序只能指定参数来指定返回的标准。 或者像我这样做，然后“序列化”LINQexpression式，并将其作为parameter passing并重新合并到服务器上的Expressions<Func<T,bool>> 。 它体面。 完成了这项工作，但是我想在客户端上使用LINQ，并使用REST在Web上翻译，这正是OData所允许的，我不想用我自己的解决scheme“黑客”。

这就像暴露“TRANSACT SQL”而不需要数据库连接string。 只需提供一个url和whoala！ 开始查询。 当然，WebApi和WCF数据服务都支持身份validation/授权，因此您可以控制访问权限，并根据angular色或其他数据configuration附加额外的“Where”语句。 我宁愿在我的Web Api层比在SQL（如build设视图或存储过程）中做到这一点。 现在，应用程序可以自行构build查询，您将看到Ad-Hoc和BI报告工具开始利用OData并允许用户定义自己的结果。 不依赖于静态报告，他们有最小的控制。

在Silverlight，Windows 8 Metro或ASP.NET（MVC，WebForms等）中开发时，只需在Visual Studio中将“服务参考”添加到WCF数据服务，然后快速开始使用LINQ查询数据，客户端上的“数据上下文”，这意味着它跟踪更改，并允许您“自动”提交您的更改返回到服务器。 这与Silverlight的RIA Services非常相似。 我将使用WCF数据服务，而不是RIA服务，但当时它不支持DataAnnotations或Actions，但现在它确实:) WCF数据服务与RIA服务相比具有另一个优势，即执行“投影”来自客户。 这可以帮助性能，incase我不想从实体返回所有的属性。 在处理业务线应用程序时，在客户端上拥有“数据上下文”非常棒。

所以，如果你的数据有关系，特别是在使用SQL Server和Entity Framework时，WCF数据服务是非常棒的。 只需很less的代码，您就可以快速地通过REST暴露Queryable Data + Actions（调用调用操作，即工作stream，后台进程）。 WCF数据服务刚刚更新。 新版本发布。 看看所有的新function。

WCF数据服务的缺点是你在HTTP协议栈上的“控制”。 我发现最大的缺陷是在返回集合的IQueryable<T>方法中。 与RIA Services AND WebApi不同的是，您没有完全访问权限来开发IQueryable方法中的逻辑。 在RIA Services和WebApi中，只要返回IQueryable<T> ，就可以编写任何你想要的代码。 在WCF数据服务中，您只能使用Expression<Func<T,bool>>拦截器方法访问“Where”语句。 我发现这令人失望。 我们目前的应用程序使用RIA服务，我发现我们确实需要控制IQueryable逻辑的能力。 我希望我错了，我只是失去了一些东西

此外，WCF数据服务还不完全支持所有的LINQ操作符。 它仍然支持比WebApi更多。

那么WebApi呢？

1. 我喜欢对Http Request / Response的控制
2. 这很容易遵循（利用MVC模式）。 我相信会有更多的工具来。

截至目前（据我了解），客户端（即Silverlight，ASP.NET服务器端代码等）没有“数据上下文”的支持，因为WebApi不是真正的实体数据模型，如WCF数据服务/ OData是。 它可以使用IQueryable / IEnumerable公开模型对象集合，但是一旦实体在客户端上被加载，就没有主键/外键“导航属性”（即customer.Invoices），因为没有“数据上下文”它们asynchronous加载它们（或者使用$ expand在一个调用中），并pipe理这些改变。 您在客户端没有代码生成“实体数据模型”的“表示”，就像在RIA服务或WCF数据服务中那样。 我并不是说客户机中没有代表您的数据的模型，但是您已经手动填充数据，并且pipe理每个“客户”将被检索到的“发票”networking。 这可能会变得棘手，尤其是所有的asynchronous事情。 你不知道哪个电话会先回来。 这里可能很难解释，但只是阅读RIA服务或WCF数据服务中的“数据上下文”的东西。 所以在处理业务线应用程序时，这是我的主要问题。 这主要基于生产力和可维护性。 您可以在没有数据上下文的情况下模仿地构build应用程序。 它只是让事情变得更加简单，特别是在Silverlight，WPF和现在的Windows 8 Metro中。 将关系实体asynchronous加载到内存中，并且拥有两个绑定是非常好的。

话虽如此，这是否意味着有一天WebApi可以支持客户端上的“数据上下文”？ 我想可以。 此外，随着更多的工具，一个Visual Studio项目可以生成所有基于数据库架构（或entity framework）的CRUD方法。

此外，我知道我只提到.NET的.NET框架，当谈到使用WCF数据服务或WebApi，但我很清楚，HTML / JS也是一个主要的球员。 我只是提到了我在处理Silverlight UI或ASP.NET服务器端代码时所获得的好处。我相信随着HTML5 / JavaScript中的“IndexedDB”的出现，它具有“数据上下文”和JavaScript中的LINQ框架也可以使用，使得从JavaScript（现在可以在OData中使用DataJS）更容易查询OData服务。 另外，使用KnockoutJS来支持HTML / JS中的MVVM和绑定，也会使它变得轻而易举:)

我目前正在研究使用哪个平台。 我会很高兴使用，但我倾向于倾向于OData的基础上，我的下一个应用程序主要是关于分析（只读）的事实，我想要一个丰富的富有performance力的RESTful Api。 我相信OData + WCF数据服务给了我，因为WebApi只支持集合上的$ take，$ skip，$ filter，$ orderby。 它不支持投影，包括（$ expand）等。我没有太多的“更新/删除/插入”，我们的数据是相当关系的。

我希望别人能够参与讨论并给出他们的想法。 我仍然在决定，并希望听到其他意见。 我真的认为这两个框架都很棒。 我想知道你是否要select，为什么不使用这两个，如果需要的话。 从客户端来说，无论如何都是build立REST调用。 只是一个想法 ：）

Answer 3

我们相信，Web API为OData服务提供了正确的平台，因此将主要投资于 OData服务器堆栈平台 。 我们当然会继续把重要的资源投入到OData核心库和客户端，但是我们打算减lessWCF数据服务的投资，作为创buildOData服务的堆栈。

OData团队博客

所以，现在看来一切都足够清晰了

Answer 4

Web API和WCF数据服务都支持OData。 使用WCF数据服务（WCFDS），它是自动的。 使用Web API，从您的控制器返回IQueryable并使用[Queryable]标记方法。 这会让你获得你所说的$filterfunction。 如果你这样做的话，都可以通过在请求头中joinaccept=application/json来自动处理JSON。 WCFDS的OData支持比Web API更多的OData关键字（虽然只有$expand关键字出现），但我相信时间可以解决这个问题。

.NET客户端和HTML页面都可以很容易地调用这两种替代方法，但是如果您喜欢LINQ，并且正在构build.NET客户端，则可以将WCFDS作为服务参考添加到您的项目中。 这允许您完全跳过所有的HTTP业务并直接查询集合。

底线是没有什么能够阻止你把.svc文件放到你的ASP.Net MVC项目中。 这不是一个无论是或命题。 将数据服务添加到您的服务器将节省您编写大量控制器的必要，但是并不妨碍您根据需要编写额外的控制器。

Answer 5

换一种说法 ：

如果您希望快速公开一个数据模型（EDM或其他），并且不需要太多的代码或业务逻辑，那么WCF数据服务将使这一切变得非常简单，并且是一个很好的起点。

如果您正在构build一个API，并且只是想使用OData查询语法或格式来公开一些资源（和逻辑），那么ASP.NET Web API可能是最好的开始。

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx

Answer 6

Devaron给出了我还没有find的WCF vs Web Api最丰富的回顾。 谢谢。 现在到WCF太复杂了，我会说复杂性不是自动消极的。 你会感激将来为你提供的呼吸室。 微软工具一直面临的挑战是我们不知道或控制未来。 我们希望微软最终能够build立一个更加统一的系统，而且这个系统还能维持几年。

我也有一个大的系统来build立，它强调我的path不是更清楚。 我计划再拖延几个月，而这一切都解决了。 而且我个人的datajs（也检查JayData）

Answer 7

这是TL，DR对这个问题的回答。

WCF是用于数据通信和传输的WEB API螺丝刀的瑞士军刀：WCF可以完成WEB API所能做的所有事情，但是如果您需要更多（例如，使用TCP协议），则WCF是最佳select。

这是一个很好的比较 。

WEB API

使用WEB API的首要原因是轻量级。 这意味着实现起来更简单，更容易学习，更容易维护等。它是专门为需要基于HTTP的RESTful Web服务的Web而devise的。 它这样做，它做得很好。 如果这就是你所需要的，那么WEB API可能就是要走的路。

另外，它是开放源代码（如果你在意）

WCF

WCF只是比WEB API做的更多：它支持多种传输协议，多种交换模式（WEB API需要与SignalR或Web套接字集成），SOAP服务可以在WSDL中描述，具有额外的安全特性等等。 如果你需要这个额外的function，请使用WCF。

的OData

OData很简单

一个开放协议，允许以简单和标准的方式创build和使用可查询和可互操作的RESTful API。 来源： http ： //www.odata.org/

换句话说，高层次，它只是标准化RESTful HTTP请求的特定语法。 这将提供与任何协议相同的好处。 至less在2013年，WCF和WEB API都允许使用OData。 所以，OData可能不值得担心。

Answer 8

简单地说就是这样，从底层协议退后一步，从开发人员/用户的angular度来看待这个问题。 Web API是微软的第一个基于HTTP的Rest框架，而不是WCF。 这意味着任何缺less的Restfunction，规格，他们将添加到Web APIpipe道，而不是WCF。

是的，你可以在WCF中自己实现这些，但正如它在句子中说的，你需要自己实现这些。

就像今天为Web API实现双因素身份validation的一个例子，使用OWIN（主要是作为开源项目启动的身份validation/授权nuget包）的时间不到15分钟。

当您使用技术堆栈时，使用Microsoft的第一个类堆栈会产生巨大的差异。 你甚至会有无数MS在Github上发布了示例代码和项目，你可以简单地复制并在你自己的项目中开始。 它在每个级别上都有所不同，文档，代码示例，function集，支持，助手api都是您命名的。

所以我对你简单的build议，如果你想构buildRestfull基于HTTP的应用程序使用Web API（或ASP.NET Core的便携性），并真正远离WCF。 如果协议不是HTTP，而且它确实不能使用HTTP，那么就使用WCF。