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開發經驗，那麼這篇文章你讀起來會很親切。
這些原則/實踐往往不是孤立的，我嘗試將他們之間用圖的方式關聯起來，幫助你在使用的過程中進行 選擇。例如，你遵循了“一切皆異步”的原則，那麼很可能你 需要進行“線程管理”和“事件管理”； 如果你需要引入“緩存與本地存儲”，那麼“數據交互模式”你也需要進行考慮。希望這張圖能夠幫助讀 者理解不同原則之間的聯系。
