WCF数据服务（OData）与ASP.NET Web API
我正在设计一个由RESTful服务和各种客户端（Silverlight，iOS，Windows Phone 7等）组成的分布式应用程序。 现在我决定使用哪种技术来实现我的服务，WCF数据服务（OData）或ASP.NET MVC 4中提供的新ASP.NET Web API。
我已经在线观看了几篇演讲，现在我倾向于使用WCF数据服务，主要是因为内置在URI和本地超媒体功能中的过滤机制。 我能看到的唯一不足就是Atom Pub规范的详细程度，而不是POX。
在作出决定之前，有什么我应该了解这两种技术？ 为什么有人会通过WCF数据服务选择ASP.NET Web API？
这是一个主观问题，所以这是一个主观答案。 IMO，WCF对于简单的RESTful服务有太多的开销。 另一方面，Web API专门为RESTful服务设计。
我在这方面与戴夫沃德达成一致。 查看他的博客获取更多信息。
我一直坚持反对在WebForms项目中从ASMX转移到WCF的压力，因为接受WCF的复杂性主要只是通过不太灵活的JSON序列化来奖励我。 相比之下，我已经开始将我的一些项目从ASMX转换为Web API，并对Web API如何轻松取代ASMX感到满意。
我相信微软终于在ASMX的简单性和WCF的Web API功能之间找到了一个很好的平衡点。
目前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数据服务终于使客户端应用程序变得更具“表现力”。 之前，我们总是不得不使用ASMX或WCF来构建僵化的Web API，这些Web API不透明，并且只要UI想要稍微不同就需要不断更改。 客户端应用程序只能指定参数来指定返回的标准。 或者像我一样做，然后“序列化”LINQ表达式并将它们作为参数传递并重新合并到服务器上的Expressions<Func<T,bool>> 。 它体面。 完成工作，但我想在客户端上使用LINQ，并使用REST在Web上翻译，这正是OData所允许的，我不想用我自己的解决方案“黑客”。
这就像暴露“TRANSACT SQL”而不需要数据库连接字符串。 只需提供一个Url和whoala！ 开始查询。 当然，WebApi和WCF数据服务都支持认证/授权，因此您可以控制访问，并根据角色或其他数据配置附加额外的“Where”语句。 我宁愿在我的Web Api层中执行此操作，而不是在SQL中执行此操作（如构建Views或Stored Procs）。 现在，应用程序可以自行构建查询，您将看到Ad-Hoc和BI报告工具开始利用OData并允许用户定义自己的结果。 不依赖静态报告他们有最低限度的控制。
在Silverlight，Windows 8 Metro或ASP.NET（MVC，WebForms等）中进行开发时，只需在Visual Studio中将“服务引用”添加到WCF数据服务，然后快速开始使用LINQ查询数据，客户端上的“数据上下文”，这意味着它会跟踪更改并允许您自动将“更改”提交回服务器。 这与Silverlight的RIA Services非常相似。 我将使用WCF数据服务而不是RIA服务，但当时它不支持DataAnnotations或Actions，但现在它的确如此:) WCF Data Services与RIA Services相比具有另一个优势，即可以执行“Projections”来自客户。 这可以帮助提高性能，因为我不想从实体返回所有属性。 在处理业务线应用程序时，在客户端上拥有“数据上下文”非常棒。
因此，如果您的Data具有关系，尤其是在使用SQL Server和Entity Framework时，WCF数据服务非常棒。 只需很少的代码，您就可以通过REST快速公开Queryable Data + Actions（调用调用操作，即工作流，后台进程）。 WCF数据服务刚刚更新。 新版本发布。 检查所有新功能。
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？
到目前为止（根据我的理解），客户端（即Silverlight，ASP.NET服务器端代码等）没有“数据上下文”支持，因为WebApi并不是真正关于实体数据模型，如WCF Data Services / OData是。 它可以使用IQueryable / IEnumerable公开模型对象的集合，但是一旦实体在客户端上加载，就没有主键/外键“导航属性”（即customer.Invoices），因为没有“数据上下文”它们会异步加载它们（或者使用$ expand在一次调用中），并管理这些更改。 您在客户端没有代码生成“实体数据模型”的“表示”，就像您在RIA服务或WCF数据服务中所做的一样。 我并不是说客户端中没有代表数据的模型，但是您已经手动填充数据并管理每个“客户”设置了哪些“发票”网络。 这可能会变得棘手，尤其是所有异步事件都在进行。 你不知道哪些电话会先回来。 这可能很难在这里解释，但只是阅读关于RIA服务或WCF数据服务中的“数据上下文”的内容。 因此，在处理业务线应用程序时，这是我的主要问题。 这主要基于生产力和可维护性。 您可以在没有数据上下文的情况下模仿构建应用程序。 它让事情变得更加简单，特别是在Silverlight，WPF和现在的Windows 8 Metro中。 将关系实体异步加载到内存中并使用双绑定非常好。
话虽如此，这是否意味着有一天WebApi可以支持客户端上的“数据上下文”？ 我认为它可以。 此外，随着更多的工具，Visual Studio项目可以基于数据库模式（或实体框架）生成所有的CRUD方法。
另外，我知道我只提到.NET框架，当谈到使用WCF数据服务或WebApi时，但我非常清楚HTML / JS也是一个主要角色。 我只是提到了我在处理Silverlight UI或ASP.NET服务器端代码等时遇到的好处。我相信随着HTML5 / JavaScript中“IndexedDB”的出现，它具有“数据上下文”和JavaScript中的LINQ框架也可以使用，从而使得通过JavaScript可以更轻松地查询OData服务（您现在可以使用DataJS和OData）。 另外，使用KnockoutJS来支持HTML / JS中的MVVM和绑定也会使它变得轻而易举:)
我目前正在研究使用哪个平台。 我很乐意使用这两种方法，但是我倾向于倾向于OData，因为我的下一个应用程序主要是关于Google Analytics（只读），并且我想要一个富有表现力的RESTful Api。 我相信OData + WCF数据服务给了我，因为WebApi只支持集合上的$ take，$ skip，$ filter，$ orderby。 它不支持Projections，Includes（$ expand）等。我没有太多的“更新/删除/插入”，我们的数据是相当关系的。
我希望别人能参与讨论并给出他们的想法。 我仍然在决定，并希望听到其他意见。 我真的认为这两个框架都很棒。 我想知道你是否必须选择，为什么不在需要的时候同时使用它们。 从客户端来说，无论如何都是建立REST调用。 只是一个想法 ：）
我们相信，Web API将为OData服务的发展提供合适的平台，因此将主要投资于该平台的OData服务器堆栈。 我们当然会继续将大量资源投入OData核心库和客户端，但是我们计划将WCF数据服务的投资减少为创建OData服务的堆栈。
OData团队博客
所以，现在看来一切都足够清晰了
链接地址: http://www.djcxy.com/p/54327.html上一篇: WCF Data Services (OData) Vs ASP.NET Web API
下一篇: What is the difference between Asp.Net Web API and WCF Service?