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

Question

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

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

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

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

既然如此:

“RIA 服务链接”的优势是什么，其中 Silverlight 应用程序直接绑定(bind)到 RIA 服务，而不是仅将服务引用添加到 OData 端点，任何类型的客户端都可以使用该端点而不会导致紧密耦合？有人告诉我 RIA 的魔力在于代码生成，所以我想我想了解 RIA 代码生成与“添加服务引用”代码生成有何不同。

如果有优势，为什么这些优势专门提供给 Silverlight 而不是 WCF 客户端应用程序？纯粹将 RIA 服务作为 OData 端点后面的一个层来销售似乎有助于标准化和进一步插入 OData，使其成为任何类型客户端的通用端点类型——“从 ASP 消费，从 Silverlight 消费，从 WCF 消费……您获得几乎相同的体验，这是一次很棒的体验。”相反，我们将 Silverlight 直接绑定(bind)到具有一组特殊功能的 RIA，以及使用开放协议(protocol)的所有其他客户端。

Answer 1

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

RIA 服务的主要优势是:

透明数据访问 - 没有摆弄 svc 文件等。你创建一个 Entity Framework 模型，将它包装在域服务中，你就完成了。更重要的是，更改会自动传播。开发人员不必在每次模型或查询更改时重新创建服务引用，代码生成会为您完成。

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

数据源模板和验证 = 可能是最容易被忽视的功能之一，但却是最重要的功能之一。您是否打开了“数据源”窗口？ RIA 服务创建支持服务器端验证注释的用户可配置 DataContext 绑定(bind)的主/详细信息控件。功能性数据绑定(bind)应用程序只需拖放即可。考虑一下这对更专注于设计/混合的人的值(value)。

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

作为说明，我对 RIA 服务和数据服务进行了大量研究，它们满足不同的需求。我们将 RIA 服务用于我们所有的桌面替换应用程序，但我们将数据服务用于 SaaS。

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