do coding(); while alive();

本文著重討論的是具有RIA特征的Web應用。例如目前比較流行的的Ajax類Web應用。傳統的基于純HTML的Web應用不在本文討論之列。

隨著Ajax的升溫，開發人員逐漸對Web應用中的各種UI控件和開發框架開始有了越來越濃厚的興趣。目前所知的這方面的控件集或開發框架可以說是并不鮮見。筆者將這些產品大致分為兩個大類：離散控件集型和數據模型驅動型。這兩個詞大家應該很陌生，因為他們都是鄙人自造的。

離散控件集型 － 此類產品以提供一系列相對獨立的界面控件為主要目的。控件的類型比較全面，例如搭建Web應用常見的各種Grid、Tree、Menu、ToolBar、Window等。不過此類產品一般不會過多的考慮界面中的數據和操作邏輯的封裝，至多只會提供相對簡單的靜態數據綁定*。我認為此類產品的主要出發點是改善Web應用的界面表現能力，同時借助自帶的SDK提供一種更加規范的開發模式。
目前我所知的大部分產品似乎都屬于這一類別。例如: backbase、qooxdoo、NetAdventage、bindows等。
Backbase實例中心: http://www.backbase.com/demos/explorer

數據模型驅動型 － 此類產品除了要提供一組比較好用的UI控件集之外，更會提供對界面中數據模型的管理功能。其UI控件以數據敏感控件為主。數據敏感控件可以通過于數據模型的綁定來實現對表現層中數據的展示和控制。這種數據綁定可成為動態數據綁定*。可以說這一類產品的主要出發點除改善Web應用的界面表現能力外，也非常注重提供一種快速開發的模式。
好的數據模型驅動型的開發框架應該首先包含離散控件集中的各種功能，它事實上是一種相對于單純的UI控件集而言更高層次的抽象。

這種模式其實在以前CS下非常常見，例如VB、Delphi等RAD開發工具提交數據庫應用開發模式都屬于這種類型。不過到了BS下人們似乎都忘記這種開發模式。可能是因為不夠見多識廣，目前筆者所知的此類產品只有dorado。
dorado的示例中心： http://sample.bstek.com

對于上面提到的兩種數據綁定方式的解釋如下：

靜態數據綁定 – 是指在控件可以根據指派給他的數據源(往往是XML數據源或簡單的數組)自動的提取并展示其中的數據。這種提取過程是主動完成的，當提取過程結束后控件無法繼續感知數據源中數據的變化。這事實上是從控件到數據源的拉模式(Pull Mode)。

動態數據綁定 – 是指將控件以觀察者的角色注冊到數據源(往往是經過封裝的私有對象)中。數據源成為被觀察者。當數據源中的數據或狀態發生改變時會主動通知所有觀察者（即綁定的控件），然后再由控件自動提取數據完成展現的更新。這樣一旦綁定建立以后控件就可以實時的體現數據源中的最新變化。如果用戶利用這些控件對數據或狀態做了改變，那么這種改變自然也會通過數據源再實時的通知給所有其它相關的控件。這事實上是從數據源到控件的推模式(Push Mode)。
?
回到關于離散控件集型和數據模型驅動型的討論。這兩種開發框架都有這自己的適用面。筆者認為離散控件集型的開發框架更加適合與一些像論壇這樣更加注重展現的應用。而對于那些具有明顯數據庫應用特性的的Web應用(例如MIS類應用)，則數據模型驅動型的開發框架更能發揮它的優勢。
得出以上結論的原因是我認為數據模型驅動型的開發框架能夠使開發人員將更多的精力投入到界面所需要實現的更能當中，至少在制作頁面的前期階段不必太多的關注界面的表現形式。同時如果能夠將更多的界面操作邏輯封裝到數據模型對象中，就可以保證在后期當最終用戶提出界面的修改要求時，開發人員可以用更小的代價來完成對界面的重構。

讓我們來具體分析兩個場景:

場景1：一個用慣了CS應用的用戶要求開發一個界面來維護公司目前擁有的所有書籍。為了方便的完成對所有書籍的CRUD操作，用戶希望以一個Grid控件來完成所有這些操作，同時用戶希望能夠在界面批量的完成一系列C、U、D操作之后一次性的對數據進行保存。每本書籍都有一個由系統自動分配的編碼作為主鍵，因此用戶不需要看到書籍的編碼。
分析：如果我們現在只有一個離散的Grid控件。要完成上述功能我們還需要做以下一些工作:

在提交時將所有的數據修改信息抽取出來組裝成可用于提交的格式。

可見如果使用一個離散的Grid控件來制作這個界面，我們還必須要做不少工作。如果我們能夠選擇一個數據模型驅動型的開發框架，上面提到的很多功能框架中往往已經具備。開發人員要做的往往只是聲明好一個數據模型然后把它跟Grid關聯起來。如果您以前使用過VB或Delphi這一類開發功能，應該不難想像這個過程。

場景2：想像一個用戶信息的錄入界面，如下圖。使用者需要輸入用戶的身份證，由于什么證的號碼中包含了很多信息，系統完全有可能從其中解析出出生日期和性別這樣的信息。因此為了方便錄入，我們可以讓表單中的出生日期和性別這兩個欄位支持自動填入缺省值的功能，只要用戶錄入了身份證號碼，就可以馬上自動填充上述兩個欄位。

?
在基于離散控件的編程方式中，我們需要知道身份證、出生日期、性別這三個編輯框的id，并針對他們進行編程。其代碼形式可能如下:

var?id? = ?inputId.getValue();? // ?獲得身份證號碼
?? // ?對身份證進行解析
inputBrithday.setValue(brithday);? // ?為出生日期設置缺省值
radioGroupSex.setValue(sex);? // ?為性別設置缺省值

在基于數據模型驅動型框架的編程方式中，我們并不需要關注界面上擺放了什么控件，只需要知道關注如何操作數據模型對象。其代碼形式可能如下:

var?id? = ?dmUser.getValue( " id " );? // ?從數據模型(dmUser)中提取身份證號碼
?? // ?對身份證進行解析
dmUser.setValue( " birthday " ,?brithday);? // ?為出生日期設置缺省值
dmUser.setValue( " sex " ,?sex);? // ?為性別設置缺省值

可見在這種開發模式中我們的代碼幾乎完全針對數據模型展開，當我們為dmUser中的brithday和sex賦值后，相應的數據敏感控件會立刻自動顯示出這些的數據。這樣的編程模式可以讓代碼有高度的一致性，當我們制作復雜的用戶界面時，可以不需要記住諸多的控件id。
進一步假設。如果用戶有一天覺得這樣的界面并不方便對多筆數據進行方便的維護，而要求對界面進行如下調整。在刪除原先的表單，利用一個Grid控件來對用戶信息進行維護。

如果我們的編程方式是基于離散控件的，那么我們不可避免的要對先前編寫那段代碼做一些調整了。我需要將那段代碼移植到表格當中。
但是如果我們的編程方式是基于數據模型驅動型框架的，那么我們要做的只是將界面上的表單刪掉，然后在放置一個與現有數據模型綁定的Grid控件。至于那段代碼，它完全不需要做任何變動。

綜上可見，在MIS類Web應用的表現層開發方面。數據模型驅動型的開發框架可以為開發人員帶來更多的實惠。不知道隨著時間的推移這一類的開發框架會不會豐富起來？