为什么要使用“RIA 服务链接”而不仅仅是 OData 端点？
在阅读之前，请注意我已经阅读了有关普通 WCF、WCF 数据服务和 RIA 服务之间差异的所有其他文章。我的问题是，为什么 RIA 服务被视为一种专门针对 Silverlight 的特殊数据源，而让 RIA 服务只做一项工作似乎更有意义：充当 REST 接口背后的业务逻辑层。
看起来随着 VS2010 的发布，RIA 服务已经巩固了其作为 REST 数据访问服务背后的业务逻辑层的地位 - 这似乎通过域服务类模板上的新“公开 OData 端点”选项得到了证实。 Visual Studio，据我所知，它对 RIA 服务的作用与 WCFDS 对任意数据源的作用完全相同（我相信您以前可以这样做，但添加此复选框清楚地表明 RIA 服务可以是被视为包含业务逻辑的层，用于增强 REST 数据端点和/或将其限制为一组给定的查询，而不一定是端点本身）。
因此，如果我有一个通过 OData 公开的具有业务逻辑的 RIA 服务，我可以从 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 绑定，并且所有其他客户端都使用开放协议。
Before reading, please know I've read all the other posts about the differences between vanilla WCF, WCF Data Services and RIA Services. My question is specifically about why RIA Services is being considered as a special kind of data source specifically for Silverlight when it seems to make more sense to just have it do one job: serve as a business logic layer behind a REST interface.
It looks like with the release of VS2010, RIA Services has solidified its stance as a business logic layer that sits behind a REST data access service - this seems to be confirmed by the new "Expose OData Endpoint" option on the Domain Service Class template in Visual Studio, which as far as I can tell essentially does for your RIA Service exactly what WCFDS does for an arbitrary data source (you could do this before, I believe, but the addition of this checkbox makes it clear that a RIA Service can be viewed as a layer containing business logic used to enhance a REST data endpoint and/or constraint it to a given set of queries, and not necessarily an endpoint in and of itself).
So, if I've got a RIA service with business logic, exposed via OData, I can add a reference to the OData service from a WCF client app. On the client, I get a DataServiceContext derivative that lets me do unit-of-work style work on the client. I can do the same thing from a Silverlight app and get what appears to be the same thing - a DataServiceContext derivative.
If I instead use a "RIA Service Link" in my Silverlight app to directly tie the app to the RIA service instead of adding a service reference, I get code generated by Visual Studio that appears to support pretty much the same patterns of work, but using a different style of API.
That being the case:
- What are the advantages of a "RIA Services link," where a Silverlight app is tied directly to a RIA Service, as opposed to just adding a service ref to an OData endpoint that can be consumed by any kind of client without incurring tight coupling? I'm told that the magic of RIA is in the code generation, so I guess I'm trying to understand how the RIA code generation differs so much from "add service reference" code generation.
- If there are advantages, why are these advantages made available specifically to Silverlight and not WCF client apps? Selling RIA services purely as a layer behind an OData endpoint seems like it would help standardize and push OData even further in terms of becoming a universal type of endpoint for any sort of client – “consume from ASP, consume from Silverlight, consume from WCF… you get virtually the same experience and it’s a great one.” Instead, we have Silverlight tied directly to RIA with a special set of functionality, and all other clients using the open protocol.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
相反，RIA 服务并不是“oData 背后的域逻辑”。 RIA 服务的目的是抽象出基于 Web 的数据访问机制，以实现 Silverlight 中的快速应用程序开发。想想 RIA
服务之于WCF就像VB之于C++一样。
RIA 服务的主要优点是：
透明数据访问 - 无需摆弄 svc 文件等。您创建一个实体框架模型，将其包装在域服务中，然后就完成了。更重要的是，更改会自动传播。开发人员不必在每次模型或查询更改时重新创建服务引用，代码生成会为您完成此操作。
开箱即用的身份验证框架 - 当您创建业务应用程序时，它就在那里，它是 VS 中的模板，是一种与现有 ASP.NET 身份验证集成的方法，而无需执行任何繁重的工作。
数据源模板和验证 = 可能是最被忽视的功能之一，但却是最重要的功能之一。您打开“数据源”窗口了吗？ RIA 服务创建用户可配置的 DataContext 绑定的主/详细控件，支持服务器端验证注释。功能性数据绑定应用程序只需拖放即可。考虑一下这对于更注重设计/混合的人的价值。
简而言之，RIA 服务是为开发人员构建的，能够在几个小时内从 edmx 数据模型转变为安全的功能性 Silverlight。当在上下文中使用时，这是很棒的东西。
需要说明的是，我对 RIA 服务和数据服务进行了大量研究，它们满足了不同的需求。我们对所有桌面替换应用程序使用 RIA 服务，但对 SaaS 使用数据服务。
不过，我认为您距离 RIA 服务的长期目标并不遥远。我想我们会看到 oData 和 RIA 服务在未来的版本中更加接近。
RIA services is not intended as "Domain logic behind oData" to the contrary and quite the opposite. The intention of RIA services is to abstract away the mechanics of web based data access to enable Rapid Application Development in Silverlight. Think of RIA
Services as to WCF as VB is to C++.
The key benefits of RIA Services are:
Transparent Data Access - there's no fiddling with svc files etc. You create an entity framework model, wrap it in a domain service and you're done. More importantly changes are propagated automagically. The developer doesn't have recreate the Service reference every time the model or a query changes, code gen does it for you.
Authentication framework out the box - It's there when you create a business app, it's a template in VS, a way to integrate with existing ASP.NET auth without having to do any heavy lifting.
Data Source Templates and Validation = Probably one of the most overlooked features but yet one of the most important. Have you opened the "data sources" window? RIA services creates User configurable DataContext bound Master/detail controls that support server side validation annotations. A functional data bound app is a drag and drop away. Consider the value of that to someone who is more Design/Blend focused.
In short RIA services is built for a developer to be able to go from an edmx data model to a secure functional Silverlight up in a matter of hours. It's awesome stuff when used in context.
As a note, I've done quite a bit of research on RIA Services and Data Services and they fulfill different needs. We use RIA Services for all our desktop replacement apps, but we use Data Services for SaaS.
I don't think you're far off with the long term intention of RIA services though. I think we'll see oData and RIA services get a lot closer in future versions.
WCF RIA 服务公开的 OData 终结点不支持查询操作并按原样返回数据。这意味着 IQueryable、排序、参数等没有任何好处。它只会暴露你的方法；故事结束。有传言称，这将在下一个版本中发生变化。然而，从 IQueryable 的服务调用角度来看，RIA 服务所提供的功能从中间层到 UI 的业务规则自动传播以及用于将验证错误传输到 Silverlight 客户端的 INotifyDataErrorInfo 都非常出色（如果您选择利用它们的话）。
The OData endpoint exposed by WCF RIA Services does not support query operations and returns data as-is. That means no benefit from IQueryable, sorting, parameters, etc. It will simply expose your methods; end of story. There is rumor that this will change in the next release however. However, what RIA Services provides from the standpoint of IQueryable on service calls, automatic propagation of business rules from the middle tier to the UI, and INotifyDataErrorInfo for flowing validation errors to the Silverlight client is outstanding should you choose to leverage them.