为什么使用"RIA Services Link"而不仅仅是OData端点？

Question

在阅读之前,请知道我已阅读有关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.

既然如此:

• "RIA服务链接"的优点是什么,其中Silverlight应用程序直接绑定到RIA服务,而不是仅将服务引用添加到任何类型的客户端可以使用而不会引起紧密耦合的OData端点？我被告知RIA的神奇之处在于代码生成,所以我想我正在努力理解RIA代码生成与"添加服务引用"代码生成的区别.
• 如果有优势,为什么这些优势专门针对Silverlight而非WCF客户端应用程序提供？将RIA服务纯粹作为OData端点背后的层来销售似乎有助于标准化和推动OData进一步成为任何类型客户端的通用类型端点 - "从ASP消耗,从Silverlight消耗,从WCF消耗......你获得了几乎相同的体验,而且它是一个很棒的体验."相反,我们将Silverlight与RIA直接绑定,具有一组特殊功能,以及所有其他使用开放协议的客户端.

Answer 1

相反,RIA服务不是"oData背后的域逻辑",而是恰恰相反.RIA服务的目的是抽象出基于Web的数据访问机制,以便在Silverlight中实现快速应用程序开发.将RIA服务视为WCF,因为VB是C++.

RIA服务的主要好处是:

透明数据访问 - 没有摆弄svc文件等.您创建一个实体框架模型,将其包装在域服务中,您就完成了.更重要的是,更改会自动传播.每次模型或查询更改时,开发人员都没有重新创建服务引用,代码为您执行此操作.

身份验证框架开箱即用 - 当您创建业务应用程序时,它就在那里,它是VS中的模板,是一种与现有ASP.NET身份验证集成的方式,无需进行任何繁重的工作.

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

简而言之,RIA服务是为开发人员构建的,能够在几小时内从edmx数据模型转变为安全功能的Silverlight.在上下文中使用它是很棒的东西.

作为一个说明,我对RIA服务和数据服务做了大量研究,他们满足了不同的需求.我们为所有桌面替换应用程序使用RIA服务,但我们使用Data Services for SaaS.

我认为你对RIA服务的长期意图并不遥远.我想我们会看到oData和RIA服务在未来的版本中更加接近.