一個(gè)純靜態(tài)的B/S系統(tǒng)的做法估計(jì)不會(huì)有太多的爭(zhēng)執(zhí)，純靜態(tài)的網(wǎng)站由美工即可完全完成，而一個(gè)動(dòng)態(tài)的B/S系統(tǒng)則需要各種角色的人的共同努力去完成，例如一個(gè)典型的團(tuán)隊(duì)角色就是業(yè)務(wù)分析師+設(shè)計(jì)師+程序員+美工來完成，傳統(tǒng)的開發(fā)過程通常是這樣：
1、業(yè)務(wù)分析師對(duì)業(yè)務(wù)進(jìn)行分析，形成業(yè)務(wù)模型；
2、美工和業(yè)務(wù)分析師一起完成靜態(tài)系統(tǒng)的制作，通常稱為系統(tǒng)原型(html or html+css+javascript)；
3、設(shè)計(jì)師根據(jù)業(yè)務(wù)分析師形成的業(yè)務(wù)模型以及需求形成系統(tǒng)設(shè)計(jì)；
4、程序員根據(jù)系統(tǒng)設(shè)計(jì)進(jìn)行系統(tǒng)功能的實(shí)現(xiàn)，同時(shí)結(jié)合系統(tǒng)原型完成界面的集成；
在這樣的一個(gè)開發(fā)過程中，1、2、3步是比較難以通過自動(dòng)化的系統(tǒng)或框架來逾越的，目前的框架也同樣是鎖定在對(duì)于第4步的提升上，我們可以看到現(xiàn)在已經(jīng)有非常非常多的框架來提升實(shí)現(xiàn)系統(tǒng)功能的效率了，但界面集成的這塊呢，仍然需要耗費(fèi)非常大的工作量，基于現(xiàn)有的框架在做界面集成時(shí)通常是采用這樣幾種方法：
● 將用于實(shí)現(xiàn)動(dòng)態(tài)性質(zhì)的代碼嵌入至html中；(例如ASP、JSP等)
● 將用于實(shí)現(xiàn)動(dòng)態(tài)性質(zhì)的代碼進(jìn)行封裝，暴露出其中用于外部傳入的參數(shù)，采用標(biāo)簽的方式嵌入至html中；(如taglib等)
● 修改現(xiàn)有的html，將其中需要綁定動(dòng)態(tài)性質(zhì)的表格或域、或元素加上一個(gè)特殊的屬性；(如tapestry的jcwid方式等)
在上面的三種界面集成的方法中，我們發(fā)現(xiàn)都需要對(duì)現(xiàn)有的html進(jìn)行一定的修改，其實(shí)按順序的可以看出界面集成的一種演變，從最早的直接嵌入至html中，到采用標(biāo)簽的方式的嵌入，又到只是增加html元素的屬性的過程，在這樣的一個(gè)演變過程中，最明顯的變化就是可以看到越來越強(qiáng)調(diào)對(duì)于html的無侵入性，為什么要這么強(qiáng)調(diào)對(duì)于html的無侵入性呢，如果做過界面集成的話就很容易發(fā)現(xiàn)，在直接嵌入代碼至html的方式的時(shí)候，功能的實(shí)現(xiàn)做起來確實(shí)比較簡(jiǎn)單，但界面集成就極為痛苦了，調(diào)試起來就更為痛苦了；在標(biāo)簽的方式嵌入html的方式中，會(huì)發(fā)現(xiàn)稍微好一點(diǎn)，至少調(diào)試起來會(huì)更方便，但痛苦仍在，在界面發(fā)生變化的時(shí)候這點(diǎn)就很明顯；在元素上加新屬性的方法調(diào)試起來就很方便了，但它的痛苦就在于還是得不斷的去手動(dòng)修改html，在界面變化頻繁的情況下還是挺麻煩的。
為什么界面集成這么的麻煩呢，要做界面集成就是為了將動(dòng)態(tài)性質(zhì)的實(shí)現(xiàn)增加到靜態(tài)的html上去，而這個(gè)步驟在現(xiàn)在還沒有什么好的框架或者說好的IDE來支撐，導(dǎo)致了現(xiàn)在的這個(gè)步驟很麻煩，這也是為什么在做系統(tǒng)的時(shí)候很多時(shí)候最怕的不是用戶所要的功能的變化，而往往是界面的變化，界面集成的這個(gè)步驟是這么的索然無味而且工作量奇大，怎么來提高這塊的效率呢？
以系統(tǒng)設(shè)計(jì)時(shí)的一個(gè)基本原則："職責(zé)單一"來看界面集成這個(gè)步驟，會(huì)發(fā)現(xiàn)其實(shí)現(xiàn)在做界面集成時(shí)通常來講都是將html的職責(zé)進(jìn)行了擴(kuò)充，使一個(gè)本來只是單純的html頁(yè)面擴(kuò)充為了一個(gè)具備動(dòng)態(tài)和靜態(tài)性質(zhì)的雙重職責(zé)的頁(yè)面，從系統(tǒng)設(shè)計(jì)角度上就可以看出這是個(gè)很明顯的問題，很明顯會(huì)導(dǎo)致的一個(gè)問題就是在修改的時(shí)候或擴(kuò)充的時(shí)候都會(huì)變得很麻煩，兩種職責(zé)不同的東西為什么一定要混淆在一起呢，在界面變化這塊很多時(shí)候可以發(fā)現(xiàn)或許只是頁(yè)面布局、頁(yè)面風(fēng)格的些許靜態(tài)變化，或許又只是其中的某個(gè)動(dòng)態(tài)表格中要增加一列，如果可以分開來管理這兩種變化不是會(huì)更方便嗎？
RIAWork遵循的就是這么一個(gè)思想，在RIAWork中非常強(qiáng)調(diào)靜態(tài)職責(zé)和動(dòng)態(tài)職責(zé)的區(qū)分，靜態(tài)職責(zé)由頁(yè)面來完成，頁(yè)面遵循標(biāo)準(zhǔn)的web頁(yè)面規(guī)則，由html+css+javascript來構(gòu)成，而動(dòng)態(tài)職責(zé)則交由另外的一個(gè)部分來完成，系統(tǒng)的一個(gè)完整的功能頁(yè)面需要由動(dòng)態(tài)職責(zé)和靜態(tài)職責(zé)來共同完成，那么這個(gè)時(shí)候很簡(jiǎn)單的可以看出需要RIAWork提供動(dòng)態(tài)職責(zé)和靜態(tài)職責(zé)結(jié)合方式的支持，為了不影響靜態(tài)職責(zé)頁(yè)面，在RIAWork中由動(dòng)態(tài)職責(zé)的描述文件來完成這個(gè)步驟，在動(dòng)態(tài)職責(zé)描述中指定綁定的html頁(yè)面，在這樣的方式下，當(dāng)我們要修改靜態(tài)相關(guān)的東西時(shí)只需去修改html、css或js，而如果要修改動(dòng)態(tài)職責(zé)的東西時(shí)則只需要修改動(dòng)態(tài)職責(zé)描述文件，在保證了職責(zé)單一的基礎(chǔ)上使得原本負(fù)責(zé)的界面集成的工作變成了一個(gè)更為簡(jiǎn)單的步驟，可以想像這樣的一種方式可以靈活的應(yīng)對(duì)靜態(tài)部分的變化，而不至于導(dǎo)致靜態(tài)部分的變化帶來整個(gè)系統(tǒng)的巨大的工作量。
系統(tǒng)中目前很容易被忽略的一個(gè)部分就是交互部分的考慮，在傳統(tǒng)的系統(tǒng)開發(fā)中，當(dāng)交互發(fā)生變化時(shí)通常會(huì)導(dǎo)致系統(tǒng)極大程度的改變，而這也是RIAWork的關(guān)注點(diǎn)，RIAWork將關(guān)注多種交互方式的實(shí)現(xiàn)，并使得使用者可通過配置即完成交互方式的改變。
功能、界面和交互三者結(jié)合在一起才共同的決定了一個(gè)系統(tǒng)的好壞，在目前用戶對(duì)于界面和交互需求還沒達(dá)到成熟的情況下，我覺得為用戶多考慮一點(diǎn)界面和交互，必然是會(huì)得到用戶更多的認(rèn)可的。
ps：可以想像如果美工在ps或dreamweaver之類的工具中可以直接選擇動(dòng)態(tài)性質(zhì)的部件(如動(dòng)態(tài)表格、動(dòng)態(tài)交互方式)來直接替換靜態(tài)性質(zhì)的部分，那是多么爽的一件事，在這樣的一種方式下，自然界面集成的工作就沒有了，^_^，或許可以關(guān)注下ps、dreamweaver的插件開發(fā)，不過這仍然需要基于一種靜態(tài)職責(zé)和動(dòng)態(tài)職責(zé)分離的基本思想上....
后續(xù)篇章：
RIAWork介紹之三：RIAWork的擴(kuò)充以及擴(kuò)展
RIAWork介紹之四：RIAWork的開放性
RIAWork介紹之五：RIAWork的靈活性以及智能性
RIAWork介紹之六：RIAWork的動(dòng)態(tài)部件