为什么使用“RIA Services Link”而不是仅仅是一个OData端点？

Question

在阅读之前，请知道我已阅读关于vanilla WCF，WCF Data Services和RIA Services之间差异的所有其他文章。我的问题特别是关于为什么RIA Services被认为是专门用于Silverlight的特殊类型的数据源，因为它似乎更有意义，因为它只需完成一项工作：作为REST界面背后的业务逻辑层。

它看起来像VS2010，RIA服务的发布巩固了其作为坐着一个REST数据访问服务背后的商业逻辑层的立场 - 这似乎被新确认“揭露的OData端点”上域选项Visual Studio中的服务类模板，据我所知，它基本上可以为您的RIA服务确实做到WCFDS对于任意数据源所做的事情（我相信您之前可以这样做，但是添加此复选框会清楚地表明RIA服务可以被看作是一个包含业务逻辑的层，用于增强REST数据端点和/或将其约束到给定的一组查询，而不一定是端点本身）。因此，如果我有通过OData公开的商业逻辑的RIA服务，我可以从WCF客户端应用程序添加对OData服务的引用。在客户端上，我得到一个DataServiceContext派生类，它允许我在客户端上完成单元工作风格的工作。我可以从Silverlight应用程序做同样的事情，并得到看起来是相同的东西 - 一个DataServiceContext派生。

如果我在我的Silverlight应用程序中使用“RIA Service Link”来直接将应用程序绑定到RIA服务而不是添加服务引用，那么我得到的Visual Studio生成的代码似乎支持几乎相同的模式的工作，但使用不同风格的API。

既然如此：

• 什么是其中一个Silverlight应用程序是直接关系到RIA服务“RIA Services链接”的优势，而不是仅仅增加一个服务裁判的OData的端点可以被任何类型的客户端使用而不会产生紧密耦合？我被告知RIA的魔力在于代码生成，所以我想我正在试图理解RIA代码生成与“添加服务引用”代码生成的差异。
• 如果有优势，为什么这些优势专门针对Silverlight而不是WCF客户端应用程序？纯粹将RIA服务作为OData端点背后的一层来销售似乎有助于将OData进一步标准化并推动OData进一步发展成为任何类型客户端的通用类型端点 - “从ASP消费，从Silverlight消费，从WCF消费...”你可以获得几乎相同的体验，而且这是一个很棒的体验。“相反，我们将Silverlight直接绑定到RIA并提供了一组特殊的功能，而所有其他客户端都使用开放协议。

Answer 1

RIA服务不是作为“oData背后的域逻辑”而恰恰相反的。 RIA服务的意图是抽象出基于Web的数据访问机制，以实现Silverlight中的快速应用程序开发。想想RIA 对于WCF的服务就像VB是C++一样。

RIA服务的主要优点是：

透明的数据访问 - 有一个与SVC文件等没有摆弄您创建一个实体框架模型，在域服务包裹它，你就大功告成了。更重要的是，变化是自动传播的。每当模型或查询发生变化时，开发人员都不会重新创建服务参考，代码gen会为您提供帮助。

认证框架开箱 - 当你创建一个业务应用程序它的存在，它在VS模板，与现有的ASP.NET身份验证集成，而不必做任何繁重的方式。

数据源模板和验证 =可能是最容易被忽视的功能之一，但却是最重要的功能之一。你打开了“数据源”窗口吗？ RIA服务创建用户可配置的DataContext绑定的主/细节控件，支持服务器端验证注释。功能数据绑定的应用程序是一个拖放。考虑一下那些更专注于设计/混合的人的价值。

总之RIA服务是专为开发人员能够从EDMX数据模型去一个安全的功能的Silverlight起来几个小时内。在上下文中使用时是很棒的东西。

作为一个说明，我已经做了相当多的研究RIA服务和数据服务，他们满足不同的需求。我们将RIA Services用于所有桌面替换应用程序，但我们使用Data Services for SaaS。

我不认为你不远了与RIA服务虽然长期打算。我想我们会看到oData和RIA服务在未来的版本中变得更加密切。

Answer 2

通过WCF RIA Services公开的OData的终端不支持查询操作，并返回数据原样。这意味着没有IQueryable，排序，参数等的好处。它只会暴露你的方法;故事结局。有传闻说，这将在下一个版本中改变。然而，什么RIA服务从IQueryable的对服务电话，从中间层到UI的业务规则自动传播，并为INotifyDataErrorInfo流验证错误Silverlight客户端的角度提供十分出众，你应该选择利用它们。