目前 WebApi 和 WCF 数据服务之间还有其他主要区别,似乎没有人提及。我希望 MS 能发表一篇比较两者的好文章。
我一直在关注 OData 和 WebApi。我总是发现一些主要区别。
首先,我不确定您的老板所说的“MS 支持 WebApi”是什么意思,是否意味着他们不支持 OData?IMO,他们都支持两者,目前有一些最小的重叠。Windows Azure 数据市场使用 OData 公开他们的数据,Azure 表存储使用 OData,SharePoint 2010 允许对其数据进行 OData 查询,MS 的其他产品也支持它,例如 Excel PowerPivot。当涉及到关系数据时,它是一个非常强大的查询框架。而且因为它是 RESTful 的,任何语言、框架、设备等都可以与之集成。
以下是我喜欢 OData + WCF 数据服务的地方:
OData + WCF 数据服务最终允许客户端应用程序在通过 Web 查询数据时更具“表现力”。以前,我们总是不得不使用 ASMX 或 WCF 来构建严格的 Web API,这些 API 变得笨拙,并且每当 UI 想要稍微不同的东西时都需要不断地进行更改。客户端应用程序只能指定参数来指示要返回的标准。或者像我做的那样“序列化”LINQ 表达式并将它们作为参数传递并重新水合到Expressions<Func<T,bool>>
服务器上。它的体面。完成了工作,但我想在客户端上使用 LINQ 并使用 REST 在 Web 上进行翻译,这正是 OData 允许的,我不想使用我自己的“破解”解决方案。
这就像在不需要数据库连接字符串的情况下公开“TRANSACT SQL”。只需提供一个网址和哇!开始查询。当然,WebApi 和 WCF 数据服务都支持身份验证/授权,因此您可以控制访问,根据角色或其他数据配置附加额外的“Where”语句。我宁愿在我的 Web Api 层中执行此操作,也不愿在 SQL 中执行此操作(例如构建视图或存储过程)。现在应用程序可以自己构建查询,您将看到 Ad-Hoc 和 BI 报告工具开始利用 OData 并允许用户定义自己的结果。不依赖于他们控制最小的静态报告。
在 Silverlight、Windows 8 Metro 或 ASP.NET(MVC、WebForms 等)中进行开发时,您只需在 Visual Studio 中将“服务引用”添加到 WCF 数据服务,然后快速开始使用 LINQ 查询数据并获得客户端上的“数据上下文”,这意味着它跟踪更改并允许您以原子方式将更改“提交”回服务器。这与 Silverlight 的 RIA 服务非常相似。我会使用 WCF 数据服务而不是 RIA 服务,但当时它不支持 DataAnnotations 或 Actions,但现在它支持了 :) WCF 数据服务比 RIA 服务有另一个优势,即能够执行“投影”来自客户。这有助于提高性能,以防我不想从实体返回所有属性。拥有“数据上下文”
因此,如果您拥有具有关系的数据,尤其是在您使用 SQL Server 和实体框架时,WCF 数据服务非常有用。您将能够通过 REST 使用非常少的代码快速公开可查询数据 + 操作(调用操作,即工作流、后台进程)。WCF 数据服务刚刚更新。新版本推出。查看所有新功能。
WCF 数据服务的缺点是您对 HTTP 堆栈的“控制”松散。我发现最大的缺陷是IQueryable<T>
返回集合的方法。与 RIA 服务和 WebApi 不同,您没有完全访问权限来开发 IQueryable 方法中的逻辑。在 RIA Services 和 WebApi 中,您可以编写任何您想要的代码,只要您返回IQueryable<T>
. Expression<Func<T,bool>>
在 WCF 数据服务中,您只能使用拦截器方法访问附加“Where”语句。我发现这令人失望。我们当前的应用程序使用 RIA 服务,我发现我们确实需要控制 IQueryable 逻辑的能力。我希望我错了,我只是错过了一些东西
此外,WCF 数据服务也不完全支持所有 LINQ 运算符。尽管如此,它仍然支持的不仅仅是 WebApi。
WebApi 呢???
- 我喜欢对 Http Request/Response 的控制
- 它很容易遵循(利用 MVC 模式)。我相信会有更多的工具出现。
截至目前(据我了解),客户端(即 Silverlight、ASP.NET 服务器端代码等)上没有“数据上下文”支持,因为 WebApi 与 WCF 数据服务/OData 等实体数据模型无关是。它可以使用 IQueryable/IEnumerable 公开模型对象的集合,但是一旦实体加载到客户端上,就没有主键/外键“导航属性”(即 customer.Invoices)可以使用,因为没有“数据上下文”它异步加载它们(或使用 $expand 在一次调用中),并管理更改。您在客户端上没有代码生成的实体数据模型“表示”,就像您在 RIA 服务或 WCF 数据服务中所做的那样。我并不是说您不能/没有代表您的数据的客户端模型,但是您已经手动填充数据并管理在通过 Web 检索到每个“客户”后要为每个“客户”设置哪些“发票”。这可能会变得很棘手,特别是在所有 Async 事情都在进行的情况下。你不知道哪些电话会先回来。这在这里可能很难解释,但只需阅读 RIA 服务中的“数据上下文”内容或WCF 数据服务。因此,在处理业务线应用程序时,这对我来说是主要问题。这主要基于生产力和可维护性。您可以在没有数据上下文的情况下构建应用程序。它只是让事情变得更容易,特别是在 Silverlight、WPF 和现在的 Windows 8 Metro 中。将关系实体异步加载到内存中并具有两个绑定非常好。
话虽如此,这是否意味着有一天 WebApi 可以在客户端上支持“数据上下文”?我认为可以。此外,借助更多工具,Visual Studio 项目可以生成基于数据库架构(或实体框架)的所有 CRUD 方法。
此外,我知道在使用 WCF 数据服务或 WebApi 时,我只是将 .NET 提到 .NET 框架,但我非常清楚 HTML/JS 也是主要参与者。我只是提到了在处理 Silverlight UI 或 ASP.NET 服务器端代码等时发现的好处。我相信随着 HTML5/JavaScript 中“IndexedDB”的出现,具有“数据上下文”和JavaScript 中的 LINQ 框架也可以使用,从而使从 JavaScript 查询 OData 服务的能力变得更加容易(您现在可以将 DataJS 与 OData 一起使用)。另外,使用 KnockoutJS 来支持 MVVM 和 HTML/JS 中的绑定也会变得轻而易举:)
我目前正在研究使用哪个平台。我很乐意使用其中任何一个,但我倾向于倾向于 OData,因为我的下一个应用程序主要是关于分析(只读)并且我想要一个富有表现力的 RESTful Api。我相信 OData + WCF 数据服务给了我,因为 WebApi 仅支持 $take、$skip、$filter、$orderby 而不是 Collections。它不支持投影、包含($expand)等。我没有很多“更新/删除/插入”,我们的数据是相当相关的。
我希望其他人加入讨论并提出他们的想法。我还在做决定,很想听听其他意见。我真的认为两者都是框架都很棒。我想知道您是否必须选择,如果需要,为什么不同时使用两者。从客户端来看,无论如何都是关于构建 REST 调用。只是一个想法 :)