一、引子
這個blog已經荒廢將近一年了，久也不寫，自然有很多的理由，但更多的怕是懶吧。不說閑話了，轉入正題。
關于基于JavaScript的RIA客戶端數據處理這個話題，我打算分成兩篇文章來寫，一篇陳述我所總結出的基于B/S結構的RIA客戶端數據處理的問題，另一篇則陳述針對這些問題我所提出的技術解決方案構架。
二、RIA？RIA！
關于RIA尤其是基于Ajax的RIA怕是屢見不鮮了吧？尤其是在Google推手之后，文字處理、表格處理、幻燈片放映這種看起來非常客戶端的應用，都可以采用Ajax的技術來實現了。作為一個關注企業級應用開發的技術人員，一個很自然的想法就會產生，是否可以采用這種技術來改進我們基于Java EE技術開發的B/S結構的企業應用呢？
先說有沒有必要，答案是肯定的。B/S被廣為詬病的一個問題就是降低了最終用戶的操作效率，以我的經驗來說，用戶雖然普遍的感到基于瀏覽器的界面要漂亮得多，用鼠標操作也很直觀，但是卻實在比以前的界面復雜而且操作困難。而且每次頁面提交后的等待也實在是對工作效率的一個降低。當然，我這里也沒有必要意義列舉B/S在客戶端的缺點，實際上這個問題是被廣泛認同的。
再說可行性，可行性分為兩種：技術上的可行性以及工程開發上的可行性。
技術上的可行性就無須驗證了，Google Reader、Gmail、Google Docs的穩定運行都是非常好的證明。
但是它是否一定適合時間要求相對比較嚴格的工程開發呢？
這就需要一個非常穩定的平臺來進行支持，而且由于工程開發的特殊性，最好還要有可視化的開發和調試環境才更有說服力。目前看來是沒有非常完善的，但是很多的Ajax框架，如Ext、GWT、Tibco GI以及服務端框架Struts2、JSF等，都在以自己的方式實現著。關于這個方面的探討我打算放到下一個系列《基于MDA的企業應用RIA解決方案》里面討論，不在這里多費口舌了。
技術上是可行的，而如果又一個非常穩定和成熟的平臺支持的話，在工程開發上也是可行的，那么這個平臺怎樣才算是穩定和成熟的呢？本系列討論的就是其中的一部分，客戶端的數據處理。
三、定義、縮略語
下面是本文中使用的技術名詞的定義以及縮略語簡介。
-
RIA：Rich Internet Application的縮寫。RIA是擁有傳統本地應用的功能和效果的Web應用。RIA一般把UI相關的處理交給了Web客戶端，但是大量的數據（包括應用的狀態、數據等）還是交給服務端處理
-
Ajax：又寫為AJAX，是"Asynchronous JavaScript and XML"的縮寫。是一種使用瀏覽器技術進行RIA開發的技術
-
ECMA Script：由European Computer Manufacturers Association（歐洲計算機制造商協會）維護的一個腳本語言標準。當前最通行的版本是ECMA-262 Edition 3，通常也被稱為JavaScript 1.5
-
dojo：由dojo foundation管理的一個開源JavaScript框架。提供了很好的JavaScript擴展，目前被IBM和Sun等大公司支持和使用
-
Json： JavaScript Object Notation的縮寫。它是一種純文本的數據對象傳輸協議，在Ajax的應用中被廣泛采用
-
CRUD：Create（創建）、Retrieve（獲取）、Update（更新）和Delete（刪除）這四種簡單的數據操作的縮寫
-
Form：本文中的Form指的是經過Ajax擴展的簡單的HTML電子表單。表單內部可以擁有很多如ComboBox、TextBox等構件。一般來說，一個表單對應著一個業務的數據對象
-
Tree：樹形顯示結構化數據的構件，由于數據是高度結構化的，往往可以采用懶加載等技術來提高性能
-
Grid：以表格形式顯示和編輯數據的UI構件。一般分為表頭（標題欄）、表身（數據列表）和表尾（合計、狀態顯示等）三個部分。其中，表頭可以是復合的表頭，而表身可以是復合的格式（Tree、Grid、ComboBox、CheckBox等）。一個Grid可以有一個復雜的Grid定義
-
Enhanced Grid：下面簡稱為EGrid，是Grid的擴展。在Grid的功能基礎之上提供了數據獲取和數據持久化的能力，可以大大的減少開發應用的時間（Ext中的Grid可以認為是一個簡化了的EGrid）
-
CodeList：代碼表，一般用在下拉列表數據處，在系統的實現中，由于性能以及標準的要求，下拉列表一般都是采用代碼保存數據，但是用戶在填寫表單的時候需要看到正常的文字而不是代碼，這就需要系統通過CodeList進行文字和代碼的轉換
-
LRU：Least Recent Used的縮寫，是一種簡單的緩存策略，如果緩存已滿，那么就釋放最近最少使用的那個緩存數據
-
REST：是REpresentational State Transfer的縮寫，是一種基于輕量級WebService協議
四、客戶端數據處理的技術場景
在本部分里將會針對下面六個分類對客戶端數據處理的技術場景進行概述
4.1 數據綁定（Data Binding）
概念：
以非常簡單的聲明方式實現Form、Grid這種數據填寫、修改構件與數據之間的對應關系。
場景：
-
Form綁定：把一個Form與一個數據對象通過聲明的方式綁定，使得Form的修改直接可以體現在數據對象中，而數據對象的修改也可以馬上由Form體現出來
-
Grid綁定：把一個Grid和一個數據對象集合通過聲明或者設置數據源的方式綁定，使得在Grid上的寫操作都可以體現在數據對象集合中，而數據對象集合的操作也可以馬上由Grid構件體現出來
-
Tree綁定：由于Tree的特殊性，與其說Tree與一個數據對象集合綁定，不如說Tree使用了一個可以根據查詢提供數據的數據來源更合適。當然，由于Tree有可能被可視化的修改（如組織機構管理），所以這個數據來源必須支持對數據的寫操作
-
其它：如菜單的綁定等，相對于上述三個都屬于非常用的綁定，而且如果上述綁定能夠實現，那么其他的綁定也可以采用同樣的技術實現
4.2 數據變更追蹤（Data Change Tracking）
概念：
對數據的整個生命周期進行追蹤。主要的目的就是可以通過記錄看出數據做了哪些改變，然后根據這些改變做出相應的處理，其使用場景有Grid的變更提示、Form修改的追蹤等。
場景：
-
Grid變更提示：在Grid中以明顯的方式提示用戶做了哪些修改
-
數據集合變更追蹤：根據變更的效果，可以有選擇的發送合適的數據給服務端進行處理
-
Form修改的追蹤：為用戶在提交Form時提示用戶哪些重要的字段進行了修改提供支持
4.3 數據訪問（Data Access）
概念：
服務端與客戶端數據傳輸的格式未必相同，而且數據對象屬性的類型等信息也需要一些Meta Data API來進行支持。所以，抽象出一個抽象的擁有Meta Data的數據訪問層是有意義的。
場景：
-
數據對象元數據信息訪問：可以通過這些元數據信息了解數據對象的各個屬性以及對應的數據類型（這一點對于Json格式的數據傳輸尤其重要，因為Json規范里面沒有DateTime類型）
-
數據寫操作的統一事件定義：通過Data Access API來訪問數據，所有的寫操作都會有統一的事件定義，在JavaScript 1.5中，普通的JavaScript對象是做不到的
-
統一的數據讀取方式：不管數據是XML格式的還是Json格式的，訪問數據的方式都是統一的
4.4 數據緩存（Data Caching）
概念：
數據緩存是指把獲得的數據以一定的策略緩存起來，以備使用的技術。Cache是客戶端數據處理中涉及到功能和性能的重要部分，原因請見下面的場景
場景：
-
離線運行的CodeList：系統如果需要離線運行，那么CodeList肯定需要客戶端緩存
-
離線表單填寫：如果允許用戶離線填寫表單，那么需要采用客戶端緩存策略保存用戶的數據
-
性能考慮：向服務端發請求，服務端查詢并返回屬于非常耗費資源和時間的操作，所以對于服務端的數據，客戶端應該有一定的緩存以及同步策略
4.5 數據查詢（Data Query）
概念：
數據查詢的概念非常簡單，根據用戶的查詢條件向服務端發送查詢請求，得到服務端返回的數據對象集合。
但由于數據查詢是系統中最常用的功能，所以，數據查詢需要非常強大的功能。簡單列舉如下。
場景：
-
樣本查詢：給出一個樣本，比如{age : 20, gender : 'male'}，返回所有符合樣本的結果
-
模糊查詢：用戶可以提供非明確的查詢參數（如李？？，查詢所有姓李的，名字為三個字的人），返回結果供用戶進一步的篩選
-
Range查詢：根據Start Index和Count返回整個大數據集中的一部分，一般用在分頁查詢處理方面，當然也可以用在其他的需要整個數據集的一部分的地方
-
邏輯查詢：采用邏輯操作對數據進行過濾查詢，比如（employee中所有滿足age < 40 && age >30 && gender = ‘male’ && married條件的員工——年齡大于30且小于40的已婚男員工），實際上上面所說的查詢都可以以某種方式歸為邏輯查詢的一種，之所以明確的提出來，是因為查詢的語法有可能有所不同，并且有些構件或者服務會對某些查詢有特別的需求或者加強的支持以簡化開發的難度，提高開發的效率
-
自定義查詢：根據用戶的需要可以對上面的查詢進行有機地結合
4.6 數據處理（Data Processing）
概念：
在數據查詢、顯示、修改和持久化的過程中，用戶有可能還需要做一些監控，以及一些自定義的操作，如過濾、排序等。這就需要一套數據處理的事件以及數據處理的方法。這些統一歸到數據處理用例中。列舉如下。
場景：
五、小結
客戶端的數據處理能力是客戶端最主要的基礎能力，它直接影響到了應用服務器的負荷以及用戶UI響應的速度和效率。所以，客戶端的數據處理支持是一個RIA平臺非常重要的考核點。可以上面的六類場景去考核各種RIA平臺，同時，它們也為我提出我的RIA客戶端數據處理解決方案提供了基礎的用例。