为什么要使用“RIA 服务链接”而不仅仅是 OData 端点？

Question

在阅读之前，请注意我已经阅读了所有其他关于 vanilla WCF、WCF 数据服务和 RIA 服务之间区别的帖子。我的问题特别是关于为什么 RIA 服务被视为一种专门用于 Silverlight 的特殊数据源，而让它完成一项工作似乎更有意义：充当 REST 接口后面的业务逻辑层。

看起来随着 VS2010 的发布，RIA Services 巩固了其作为位于 REST 数据访问服务后面的业务逻辑层的立场 - 这似乎通过域服务上的新“公开 OData 端点”选项得到证实Visual Studio 中的类模板，据我所知，它对您的 RIA 服务的作用与 WCFDS 对任意数据源的作用完全相同（我相信您以前可以这样做，但是添加此复选框可以清楚地表明 RIA服务可以被视为一个包含业务逻辑的层，用于增强 REST 数据端点和/或将其约束到给定的一组查询，而不一定是端点本身。

因此，如果我有一个通过 OData 公开的具有业务逻辑的 RIA 服务，我可以从 WCF 客户端应用程序添加对 OData 服务的引用。在客户端，我得到了一个 DataServiceContext 派生类，它可以让我在客户端上进行工作单元样式的工作。我可以从 Silverlight 应用程序中执行相同的操作，并获得看似相同的内容 - DataServiceContext 派生项。

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

既然如此：

• “RIA 服务链接”的优点是什么紧耦合？有人告诉我 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 服务用于所有桌面替换应用，但我们将数据服务用于 SaaS。

不过，我认为您与 RIA 服务的长期意图相去甚远。我认为我们会看到 oData 和 RIA 服务在未来的版本中变得更加接近。

Answer 2

WCF RIA 服务公开的 OData 终结点不支持查询操作并按原样返回数据。这意味着 IQueryable、排序、参数等没有任何好处。它只会暴露你的方法；故事结局。然而，有传言说这将在下一个版本中改变。但是，从 IQueryable 的服务调用、业务规则从中间层到 UI 的自动传播以及用于将验证错误流向 Silverlight 客户端的 INotifyDataErrorInfo 的角度来看，RIA 服务提供的功能非常出色，如果您选择利用它们的话。