在阅读之前，请知道我已阅读有关vanilla WCF，WCF数据服务和RIA服务之间差异的所有其他帖子。我的问题是具体地说明为什么RIA Services被认为是专门针对Silverlight的一种特殊数据源，因为它似乎更有意义让它完成一项工作：作为REST接口背后的业务逻辑层。
看起来随着VS2010的发布，RIA Services巩固了其作为REST数据访问服务背后的业务逻辑层的立场 - 这似乎得到了域服务上新的“Expose OData Endpoint”选项的证实Visual Studio中的类模板，据我所知，对于你的RIA服务来说，它确实是WCFDS为任意数据源所做的事情（我相信你可以做到这一点，但是这个复选框的添加清楚表明了一个RIA可以将服务视为包含业务逻辑的层，该业务逻辑用于增强REST数据端点和/或将其约束到给定的查询集，而不一定是其自身的端点。
所以，如果我有一个带有业务逻辑的RIA服务，通过OData公开，我可以从WCF客户端应用程序添加对OData服务的引用。在客户端上，我获得了一个DataServiceContext派生物，它允许我在客户端上进行工作单元样式工作。我可以从Silverlight应用程序执行相同的操作，并获得看似相同的东西 - DataServiceContext派生。
如果我在我的Silverlight应用程序中使用“RIA服务链接”直接将应用程序绑定到RIA服务而不是添加服务引用，我会获得Visual Studio生成的代码，它似乎支持几乎相同的模式工作，但使用不同风格的API。
情况就是这样：
答案 0 :(得分：5)
RIA服务的目的并不是“oData背后的域逻辑”，恰恰相反。 RIA服务的目的是抽象出基于Web的数据访问机制，以便在Silverlight中实现快速应用程序开发。想想RIA 作为VB的WCF服务是C ++。
RIA服务的主要好处是：
透明数据访问 - 没有摆弄svc文件等。您创建一个实体框架模型，将其包装在域服务中，然后就完成了。更重要的是，更改会自动传播。每次模型或查询更改时，开发人员都没有重新创建服务引用，代码为您执行此操作。
认证框架开箱即用 - 当您创建业务应用程序时它就在那里，它是VS中的模板，是一种与现有ASP.NET身份验证集成的方式，无需进行任何繁重的工作。 / p>
数据源模板和验证 =可能是最容易被忽视的功能之一，但却是最重要的功能之一。你打开了“数据源”窗口吗？ RIA服务创建用户可配置的DataContext绑定主/细节控件，支持服务器端验证注释。功能数据绑定应用程序是一个拖放。考虑一下那些更注重设计/混合的人的价值。
简而言之，RIA服务是为开发人员构建的，能够在几小时内从edmx数据模型转变为安全功能的Silverlight。在上下文中使用时，这是非常棒的东西。
作为一个说明，我对RIA服务和数据服务做了大量研究，他们满足了不同的需求。我们为所有桌面替换应用程序使用RIA服务，但我们使用SaaS数据服务。
我认为你对RIA服务的长期意图并不遥远。我想我们会看到oData和RIA服务在未来的版本中更加接近。
答案 1 :(得分：0)
WCF RIA Services公开的OData端点不支持查询操作并按原样返回数据。这意味着IQueryable，排序，参数等没有任何好处。它只会暴露你的方法;故事结局。有传言说，这会在下一个版本中发生变化。但是，如果您选择利用它们，从服务调用的IQueryable，从中间层到UI的业务规则的自动传播以及用于将验证错误流向Silverlight客户端的INotifyDataErrorInfo提供的内容都是非常出色的。