《软件架构》RIA 架构

原文地址

RIA（富Internet应用程序）是web应用程序的特殊种类，其用户界面的功能比第一代和第二代web应用程序丰富得多。这种web应用程序看起来更像是桌面应用程序。RIA的用户界面通常使用HTML5 + JavaScript + CSS3, Flex (Flash), JavaFX, GWT, Dart等等RIA工具开发。从长远来看，HTML5 + JavaScript + CSS3的各种变体似乎会成为主流（可以将GWT和Dart编译为JavaScript）。

RIA用户界面更加丰富的GUI客户端功能也让web应用程序的内部架构和设计有所变化。与第一代和第二代的web应用程序相比，RIA用户界面和其后端通常分离地更加干净。这使RIA GUI更加独立于服务端，同样因此GUI开发人员和服务端开发人员可以并行协作。我将在本文中说明RIA如何做到上述事情，在此之前我先介绍下第一代和第二代web应用程序的内部设计通常是怎样的。

第一代Web应用程序

第一代web应用程序是面向页面的。你将在同一个web页面里包含所有的GUI逻辑和应用程序逻辑。当浏览器发起请求时，web服务器将执行该脚本，生成对应的web页面。在同一个页面脚本中，GUI逻辑和应用程序逻辑混在了一起。这种架构和设计如下图所示：

由于是面向页面的，应用程序的每个功能都通常嵌在自己独立的web页面中。每个脚本就像一个单独的事务，执行应用程序逻辑，执行完成后生成GUI，然后将其发送回浏览器。第一代web应用程序的页面性质如下图所示：

这个GUI相当的笨重。浏览器显示了一个页面。当用户点击页面中的某些内容时，浏览器通常重定向到一个新页面中（脚本）。

第一代web技术包括Servlet（Java）、JSP（JavaServer Pages）、ASP、PHP、Perl中的CGI脚本等等

使用过第一代web技术的人都会知道，这种设计方式就是一团乱麻。GUI逻辑和应用程序逻辑混在一起，当你想对其中之一进行修改时，常常很难找到真正需要修改的地方。代码复用率也很低，因为代码分散在大量独立的web页面脚本中。需要跨越多个页面维护GUI状态（例如按下按钮），必须将这些状态保存在服务端的会话数据中，或者每个页面请求都要带上这些信息并返回给浏览器。如果你想给web脚本换一套编程语言（比如从PHP换成JSP），那你基本上就需要将这个web应用程序完全重写一次。这简直就是一场噩梦。

第二代Web应用程序

在第二代web应用程序中，开发人员找到了将服务器上的GUI逻辑与应用程序逻辑分离的方法。与第一代的将代码分布在多个页面上相比，Web应用程序也变得更加面向对象。通常，web页面脚本用来编写GUI逻辑，实际的类和对象用来编写应用程序逻辑。第二代Web应用程序设计如下图所示：

框架的开发目的是帮助简化第二代web应用程序的开发。第二代web应用程序框架主要有是ASP.NET(.NET), Struts + Struts2(Java), Spring MVC(Java), JSF(JavaServer Faces), Wicket(Java), Tapestry(Java)等等。在Java社区中，出现了两种类型的框架设计。Model 2和基于组件的框架。我不会在这里深入探讨他们之间的差异，因为我认为这两种设计都已过时。

第二代web应用程序比起第一代的确更加容易进行开发，但它们仍然存在一些问题。尽管GUI逻辑和应用程序逻辑得到了更好地分离，这两者仍然会混在一起。同样，由于GUI逻辑与应用程序逻辑使用了相同的语言编写，因此更改编程语言意味着再次重写整个应用程序。此外，由于第二代web应用程序技术的局限性，做出来的GUI通常比人们习惯的桌面应用程序的GUI更原始。因此，即使第二代web应用程序技术向前迈了一步，用起来还是比较痛苦?。

RIA Web 应用程序

RIA（富Internet应用程序）web应用程序是第三代web应用程序。 RIA web应用程序以其接近桌面应用程序的用户界面而闻名。

为了实现这些更高级的用户界面，通常在浏览器中使用JavaScript，Flash，JavaFX或Silverlight来执行RIA技术（据我所知，Flash和Silverlight均已淘汰，但我可能是错的(PS:并没有错)）。RIA Web应用程序体系结构和设计如下图所示：

如你所见，GUI逻辑现在已从web服务器移至浏览器。这种与服务器逻辑完全分离的方式对应用程序的设计和体系结构有好处也有坏处。

第一，借助RIA技术，GUI可以变得更加先进。这本身就是一个优势。

第二，由于GUI逻辑是在浏览器中执行的，因此生成GUI所需的CPU负载从服务器转移到了客户端（浏览器），从而有了更多CPU周期来执行应用程序逻辑。

第三，GUI状态可以保留在浏览器中，从而进一步简化RIA web应用程序的服务器端。

第四，由于GUI逻辑与应用程序逻辑完全分离，因此开发可重用的GUI组件变得更加容易，无论应用程序逻辑使用哪种服务器端编程语言，都可以重用GUI逻辑。

第五，RIA技术通常与web服务器通信交换数据而不是GUI代码（HTML，CSS和JavaScript）。我们一般使用HTTP发送XML格式或JSON格式的数据来进行数据交换。这将服务端从“面向页面的”变为执行某些应用程序逻辑（创建用户，登录，存储任务等）的“面向服务的”。当服务端完全摆脱生成GUI的束缚时，你的应用程序逻辑将变得非常清晰。你的应用程序逻辑接受一些数据并返回一些数据，不再需要考虑其他事情。不用考虑GUI状态、不用考虑GUI生成等等，开发工作将大大受益。的确，你的应用程序逻辑仍然需要生成XML或JSON格式数据，但这比生成GUI容易太多太多，并且更接近于应用程序逻辑和数据模型。

第六，由于服务器上的GUI和应用程序逻辑通常通过HTTP + JSON或HTTP + XML进行通信，因此GUI编程语言100%独立于服务端编程语言。服务器的GUI逻辑接口只是HTTP调用。这就意味着你的服务端和客户端分别独立更改自己的编程语言和工具，而不会对另一端产生影响。

第七，由于GUI逻辑和应用程序逻辑完全分开，并且它们之间的唯一接口是HTTP + JSON / XML，因此GUI和应用程序逻辑也可以彼此独立地开发。应用程序逻辑开发人员可以独立于GUI开发服务端并对其进行测试。GUI逻辑开发人员则可以创建一个伪（模拟）服务，该服务返回开发GUI所需的数据，他就可以开发和测试GUI。一旦真正的服务准备就绪，就可以便捷的将模拟服务替换为真实服务。

第八，由于后端仅由发送和接收数据的服务组成，因此以后在需要时添加其他类型的客户端要容易得多。比如，你可能想要添加一个可以和你后端服务交互的原生iOS或安卓应用客户端。

第九，由于后端现在由接收和发送数据的简单服务组成，因此您的web应用程序自然为“开放式”做好了准备，可以通过GUI和API来访问web应用程序（一旦你的用户需要编写程序来与您的web应用程序进行交互）。

第十，由于GUI和后端服务仅交换数据，因此与后端必须同时发送数据，HTML，CSS和JavaScript相比，流量负载通常较小。因此，您的带宽需求可能会下降（但是有时您最终会发送比其他情况更多的小请求，因此可能彼此抵消）。

如你所见，从表面上看，我们开发web应用程序的方式似乎变化不大，但实际上产生了很多额外的好处。一旦在实际项目中体验了这些优势，你就回不去了。

下图是RIA体系结构的详细示意图，你可以看到各个模块的职责分离（因此从理论上验证了我上面提到的优点）：

当然，RIA技术也会带来一些负面影响。GUI逻辑与应用程序逻辑的完全分离有时意味着GUI逻辑与应用程序逻辑将使用不同的编程语言来实现。你的GUI逻辑可以用JavaScript，ActionScript(Flash)或Dart实现，而应用程序逻辑可以用Java，C#或PHP实现。Java开发人员可以通过Google Web Toolkit(GWT)来使用Java编写JavaScript GUI。新的RIA技术意味着开发人员团队必须掌握更多技术。这当然是不利的。但是，鉴于RIA web应用程序所具有的优势，我认为这是可以接受的。

RIA 技术

以下是一些著名RIA技术的列表：

• HTML5 + CSS3 + JavaScript + JavaScript frameworks
  • jQuery
  • jQuery Mobile
  • AngularJS
  • Sencha EXT-JS
  • SmartClient
  • D3
  • Dart
• GWT (Google Web Toolkit)
• JavaFX
• Flex (Flash)
• Silverlight (now unsupported)

我的看法是，世界正朝着HTML5 + CSS3 + JavaScript RIA解决方案发展，而不是Flex和JavaFX。微软已经关闭了他们的Silverlight的开发，我怀疑JavaFX甚至Flex将来也会以同样的方式发展。但这仅仅是猜测。