RIA原则与实践（上）

RichClient/RIA原则与实践（上）2011-09-21 infoq 陈金洲Web领域的经验在过去十多年的不断的使用和锤炼中，整个开发领域的技术、理念、缺陷已经趋于成熟。JavaEE Stack, .NET Stack, Ruby On Rails等框架代表了目前这个技术领域的所有经验积累。这样我们在开始一个新的项目的时候，只需要选择对应语言的最佳实践，基本上不会犯大的错误。例如，如果使用Java开发一个新的Web应用，那么基本上Spring/Guice+Hibernate/iBatis/+Struts /SpringMVC这种架构是不会产生重大的架构问题的；如果使用RoR那么你已经在使用最佳实践了；系统的分层：领域层，数据库层，服务层，表现层等等；为了保证系统的可扩展性，服务器端应当是无状态架构，等等。总而言之，web开发领域，它丰富的积累使得开发者逐渐将更多的精力投入到应用本身。

来看富客户端，或者富互联网应用。在我看来，今天的RichClient与RIA已经没有分别：只要代表着丰富界面元素和丰富用户体验，需要与服务器进行交互的应用都可以称为RichClient或者RIA，虽然感觉上 RichClient更“企业化”一些（服务器往往在企业内部），RIA更“个人化”一些（服务器往往处于公网）。从最小的层面来说，我现在正在使用的离线模式的GoogleDoc就是一个RichClient应用──虽然它没有那么 Rich，采用和microsoft office一样土的界面; 我现在正在听音乐的Last.fm客户端显然是一个非常典型的RIA──它所有的个人喜好信息、音乐全都来自远在美国的服务器。本地的这个界面，只是提供收集个人和音乐信息，以及控制音乐的播放和停止；目前拥有1150万玩家的魔兽世界，则是一个挣钱最多的，最“富”的客户端，10多G的客户端包含了电影品质的广阔场景，华丽的魔法效果和极其复杂的人机交互。

如今的用户需求已经达到了一个新的高度，那些灰色的，方方正正的界面已经逐渐不能够满足客户的需求。从我们工作的客户看来，他们除了对“完成功能”有着基本的期待外，对于将应用做得“酷”，也抱有极大的热情。我工作的上一个项目是一个CRM系统，它是基于.NET Framework 3.5的一个 RichClient应用。它的主窗口是一个带着红色渐变背景的无边框窗口，还有请专业美工制作的图标，点击某一个菜单还有华丽的二级菜单滑动效果。我们在这个项目中获得了很多，有些值得借鉴，有些仍然值得反思。我仍然记得我们在项目的不同阶段，做一个技术决定是如此的彷徨和忐忑：因为在当时的 RichClient企业开发领域，几乎没有任何丰富的经验可以借鉴，我们重新发明了一些轮子，然后又推翻它；我们偏离了UI框架给我们提供的各种便利而自己实现种种基础特性，只是因为他们偏离了我们所倡导的测试性的原则。在写下本文的时候，我尝试搜索了一下，仍然没有比较深入的实践性文章来介绍企业环境下RichClient开发。大多数的书，如Swing、JavaFX、.NET WPF开发等等，偏向于小规模特性介绍，而在大规模的企业应用中，这些小的技巧对于架构决策往往帮助很小。

我的工作经历应当是和大多数开始进行RichClient开发的开发者类似：有着丰富的Web开发的经验之后开始进行RichClient开发。加入 ThoughtWorks之后参加了多个不同的RichClient项目的开发工作，使用/ 尝试过的语言包括Java Swing, Flex/Adobe Air, .NET WinForm/.NET WPF. 对于不同平台之间的种种有些体会。在这里我将这些实践和原则总结如下。例子很可能过时，毕竟华丽的界面框架层出不穷，但原则应当通用的。使用和遵循这些原则将会帮助你少犯错误──至少比我们过去犯的错误要少。如果你拥有一定的web开发经验，那么这篇文章你读起来会很亲切。

这些原则/实践往往不是孤立的，我尝试将他们之间用图的方式关联起来，帮助你在使用的过程中进行选择。例如，你遵循了“一切皆异步”的原则，那么很可能你需要进行“线程管理”和“事件管理”；如果你需要引入“缓存与本地存储”，那么“数据交互模式”你也需要进行考虑。希望这张图能够帮助读者理解不同原则之间的联系。