译文：.NET RIA Services: 从设想到架构（.NET RIA Services: From Vision to Architecture）

原文链接：http://www.nikhilk.net/NET-RIA-Services-Vision-Architecture.aspx  

深入到.NET RIA Services的思考，背后的概念以及架构。。。

.NET RIA Services现在已经公布了。在MIX上人们普遍都很喜欢我们在这个领域所做的一切，这是一个良好的开端。我们还没有一个好的网站来展示这个技术，但这里是目前下载页面上在说的：
      微软的.NET RIA Services通过集成ASP.NET和Silverlight平台简化了传统的n层应用模式。.NET RIA Services提供了一个模式来写运行在中间层和控件上来访问数据并进行查询、修改和定制操作的应用程序。它还提供了对普通的端到端的任务的支持，如数据验证，认证和角色，通过结合客户端的Silverlight的组件和中间层的ASP.NET。

这是一个相当简要的介绍。还有一个资料我建议看看来获得关于基本用法的第一手的感受。在这篇文章中，我想分享一些想法和架构的概念。这将使文章变得很长，但我希望它是有用的，并能对评估和欣赏.NET RIA Services提供深刻的见解。

当我们当初望着Silverlight的规划的时候，我们意识到RIA(Rich Internet Applications)的开发非常难。在客户端和服务器之间有太多的移动的碎片需要手工地把它们缝合在一起。有太多反常的东西，但却是规范，首先是n层（很多开发人员习惯于写2层的应用程序），异步（但同步却是规范），处理延时（这样做如果不恰当的话有可能破坏终端用户的体验），搞清楚如何更好阅读，处理验证、冲突、中断或偶尔连接的情况，进行验证并且在客户端和服务器端共享用户状态，不胜枚举...
我们希望简化RIA开发...并为主流的开发带来高的效率，就像ASP.NET 1.0为客户端应用程序开发人员提供一个高效率的平台来开发Web应用程序一样。钟摆已经在摆动，到了该简化RIA式客户端开发的时候了。
由于多种原因，我想把.NET RIA Services和我们正在做的事情叫做RAD for RIA（Rapid Application Develop for Rich Internet Application）。

在一种新的光线下看RIA
.NET RIA Services所带来的最大的价值主张是用一个统一的标准的眼光将客户端和服务器端看成一个逻辑相同的应用程序的两半。这两半不是两个单独的应用程序。简单地说，我们希望在不牺牲良好的n层设计并且不破坏基本原则的情况下使开发像开发2层应用程序那么简单。
让我们看看一个典型的Web应用程序的解剖图（大部分Ajax应用程序不会显著地不同）。

Web应用程序的中间层会与一个或多个后端数据库和服务打交道。它包含了一个数据模型和数据访问层来定义应用程序需要检查的东西，还包含了应用程序逻辑来限制可以用这个应用程序来做什么，最后还包含了一些显示逻辑，通常是来规划如何在浏览器中显示HTML。大部分的应用程序放在服务器上，这样让访问不同功能的代码变得很简单。
在RIA中，大部分显示逻辑被移到了客户端来改善用户体验并且能有效地利用本地的状态。其结果是给开发人员带来更多的工作量：定义一个完整的服务层，新的类型和合同等，并随着任何一端应用程序的变化持续地完善他们。
我们看到了一个隐隐约约有点不同的图片-一个更宽的单独的叫做Rich Internet Application的盒子。RIA不仅仅是一个客户端应用程序，而是一个包含了一个服务器端组件的“互联网”应用程序。

表现层被网络分开了，但是.NET RIA Services介入并在幕后提供了管道来让程序总体上保持一个2层的感觉。剥掉一个层，在盖子的下面，你会看到熟悉的建筑模块：良好的服务，开放的/标准的协议（底下有更多关于这方面的介绍）。他们只是你没有必要把重点放在上面的执行的细节。相反，你可以把重点放在你的应用程序的逻辑以及用户界面上。
当你看着完整的图片（其中包括其他独立发展的应用程序），具体的深思熟虑过的服务和明确的合同仍然被强烈的推荐。这并不会随着.NET RIA Services改变。
在客户端与服务器之间的网络仍然是非常真实的。我们的目标不是用魔术来隐藏它。但是我们要处理这种信任边界点的潜伏期，通过把相关的因素纳入编程模型，使它们自然，并简化相关的加工。
这种新的看RIA的眼光让我们做的事：
     . 分享行为、应用程序语义、元数据，甚至是执行，不仅仅是层级之间的合同。应该在同一应用程序的所有范围内。为什么要做相同的事情两次？
     . 准备好工具来处理你要建设的东西-RIA。这里有很多事情需要我们去做。随着时间的流逝...

一个具体的，端到端的，应用程序模式
我应该用一句话来为本节做序言：没有一个单独的有效的模式。很多人认为只有一个模式能工作。我认为并非如此。因此，我们在这里提到的模式会对一些应用程序起作用，但并非所有。我们对于那些想扩展模式或将它应用到他们的特殊的情况和看法的人提供了很多可扩展的地方。
端到端应用程序模式围绕着数据和特定域的逻辑。有趣的是我们正在让很多应用程序开发人员已经做的事变得更具体，而不是让它成为开发人员的练习，这样的话它能够变得更加主流。
以我在MIX上的演示为例，我有一个简单的数据模型的产品和分类的实体。
 
我们的模式的第一部分是写DomainService类。它代表着你的应用程序域，你的应用程序逻辑或业务逻辑。它表面上有一组客户端能看到的数据，这些可能是数据层类型，或者专门用于展示层的投射类型，或两者兼而有之。它还有一套操作：既能进行增删查改又能进行自定义域的操作。它还指定了针对这些数据和操作的规则，如授权和验证。最后它还包括了数据层的很多细节。DomainService被优化成为无国籍的-可以响应查询请求，并能改变设置处理请求。
模式的第二部分是我们生成的-客户端的数据模型-在一个叫DomainContext的类里。这个类代表了客户端可以看到的视图。它包含了一组对象，每一个暴露给客户端的类型对应一个对象，它还包含了一套负载的方法，大致地对应着服务上暴露出来的查询。这些负载的方法可以用来将对象加载到相应的清单。这些对象和清单会跟踪变化并发出变更通知。该DomainContext可以提取所有的变化，创建一个改变设置，并提交给服务来进行处理和承诺。DomainContext被优化来利用状态的环境，并成为一个守规矩的公民在使用绑定为中心的展示技术中，如Silverlight或WPF。
当你剥掉了一层，你会看到，基础设施是建立在你熟悉的服务和代理的建筑砌块，并且继承了服务设计时的质量。 
唯一的区别是，因为你在应用程序的范围内，基础设施更接近通过加工和运行框架功能提供的管道。特别是DataService上的服务器，它是一个诚实善良的HTTP终端要么使用REST要么使用SOAP，通过XML或JSON（通过WCF和ADO.NET数据服务在更长的时间内执行）。在客户端上，DomainContext担任一个知道基本数据语义专门代理知道的基本数据的语义。

一个可以升级的模式
用来写你的应用程序逻辑的DomainService本身并不局限于在Silverlight连接后端的关系型数据库的RIA上。这只是一个更大的故事中的一小片。

 
该DomainService模式可以与各种各样的来自简单的老的CLR类型的数据源一起工作，这可能是制造自稀薄的空气，然后从云存储那获得，如Azure，或取自一个数据库，但是是通过存放层。在我们发布的东西里，我们支持Linq到SQL和Linq到实体。在我的演示里，我展示了Azure和CLR类型。我们计划分享更多的细节关于如何使用更多种类的后端数据接入技术。
另一方面，我们有Silverlight和WPF代表.NET到.NET的故事。然而，DomainService顶部的基础设施是在一个开放的/标准的/宁静的方式下进行。因为这些脚本/ Ajax客户端能与中间层工作通过使用任何Ajax框架。服务器端使用Web Forms或MVC的基于显示的应用程序可以使用相同的应用程序逻辑。最后，对于非用户界面的客户端，如其他应用程序，可以建立一个服务层通过SOAP或REST接口来规划数据和业务。我的MIX演示包含一个Ajax和ASP.NET惯例的范例。
你建的DomainService是个具体的、有形的资产在整体的应用程序中，它可以重复使用，并成为从系统的其他部分提取数据层的中心点。因此，通过一套单元测试以确保高品质和可维护性可能是有趣的。事实上，一个单元测试就是另一个应用程序逻辑的客户端。我的MIX演示有这样的一个例子。

一个超越了CRUD的模式
关于这个模式的最后一部分我想在这篇已经很长的文章中介绍给大家的是它如何与我们的应用服务关联的故事，以及他们是如何处理具体的应用情况，同时在DomainService + DomainContext和CRUD的基础上进行建设。这些应用服务将生产力提升到一个更高的水平上，通过为通用的任务和场景提供现成的解决方案，同时又是可扩展以及可热插拔的，多亏了地基。
让我们看看我们发布的一个现成的应用服务 --- 验证(Authentication)。具体来说它包括登录，基于角色的授权和管理用户设置。而且它可以在服务器端和客户端做到这样 --- 请记住，单一的应用，单一的一套模式，适用于这两个层。验证(Authentication)继承自DomainService。它所暴露出来的实体或数据是一个用户对象。除了获得当前用户，它还可以进行一些操作，如登录和注销。然而，验证(Authentication)本身所暴露出来的应用程序接口(API)没有CRUD的感觉。相反，它看起来像一个为验证的特定的情况而做的特定的API。
同样，我们可能会看到其他应用服务，如用户注册(UserRegistration)，诊断(Diagnostics)，分析(Analytics)，应用程序白板(ApplicationWhiteboard)等。每个都提供了一个特定域的API，但会建造在DomainService + DomainContext和CRUD的基础上。

总结
尽管是惯例，但我想我们有一个非常灵活的技术搭建在一些可以被更换的构建模块上。一小部分的例子：
    例如，你可以在应用程序逻辑或DomainService模式上写自己的具体的服务，你还可以在你的客户端创建一个具体的服务引用，如果你更希望在各个层之间变得明确，而不是使用所有的基础设施。
    你可以插入自己的后端存储，如果是我们提供的不符合你的需求。例如，你可以插入一个丰富的域模型。
    你可以决定要暴露多少的数据层，而不是建设一个明确的表示类型。

我们还有别的办法。在许多方面我们展示的只是第一步。还有失踪的部分，和新的领域需要我们去处理。这就需要你加入进来-通过你的反馈意见来进一步评估该技术。