論壇系統的開發與設計畢業論文-資料下載頁

　　

【正文】 然了，仍然有一些有待改進的地方，但這是一個好的開始。OK，電子表格就是一個富客戶端程序了嗎？當然不是。在電子表格或者類似的桌面應用中，業務邏輯和數據模型是在一個封閉的環境中運行的。在這個環境中，它們彼此清晰地了解對方，并且可以互相訪問，而環境之外的東西，對于它們來說是未知的（圖12）。那么客戶端又 是什么呢？它是與另一個獨立的進程相互通信的程序，后者通常運行在服務器上。一般來說，服務器總是要比客戶端大一些，能力強一些，配置更好一些，因為在服 務器上通常要存儲浩如煙海的信息。客戶端程序使得最終用戶可以查看和修改這些信息，當多個客戶端連接在同一個服務器上的時候，可以在它們之間共享這些信 息。圖13展示了一個簡單的客戶/服務器架構在現代的n層架構中，服務器往往要和更遠的后端服務器（例如數據庫）通信，因此被稱作“中間件”的層同時扮演著客戶端和服務器的角色。我們的Ajax應用位于這個鏈的一端，它僅僅是作為客戶端，因此為討論方便，我們可以把整個n層系統看作是一個標記為“服務器”的黑盒。我的電子表格應用只需要管理它自己保存在內存或本地文件系統中的少量數據。如果架構設計良好的話，數據和它的表現形式的耦合可以非常松散，但是我不能通過網絡來分割或者通過網絡來共享它們。從這個意義上來說，電子表格應用不是一個客戶端。與之相對應的Web瀏覽器就是一個典型的客戶端，它與Web服務器通信，請求需要的頁面。瀏覽器有豐富的功能，用來管理用戶的瀏覽行為，常見功能有回退按鈕、歷史列表和分頁瀏覽多個文檔等等。但是當我們把特定網站的Web頁面看作是一個應用時，這些通用的瀏覽功能實際上和應用關系不大，充其量也就如電子表格和Windows的開始按鈕或者窗口列表之間的關系。我們來考察一下現代的Web應用。為了簡單起見，我們選擇了“地球人都知道”（圖14）。在瀏覽器中打開Amazon網站，因為在此之前我訪問過，它會給我顯示一個友好的問候、一些推薦書目，還有我的購買歷史信息。點擊推薦書目中的任何一條，就會轉到另外一個頁面（此時，頁面要刷新一下，在這幾秒鐘內我什么也看不到）。新頁面是該書的相關信息：書評、二手書報價、同一作者的其他著作，以及以前我瀏覽過的其他書籍簡 而言之，呈現在我面前的是非常豐富的、關聯度很高的信息。但是對我而言，交互的方式就是點擊那些超鏈接，然后填寫一些表格。假設我在鍵盤前面不小心睡著 了，第二天才醒來，如果不刷新頁面，我就沒法知道《哈里波特》系列的新書已經出版了，也不能將我的列表從一個頁面帶到另一個頁面，我要是想同時看到更多 一些東西也不行，因為我無法改變頁面上局部內容區域的大小。我似乎是在批評Amazon的界面，其實并非如此，我只是拿它來做個例子。事實上，在傳統Web開發方式的桎梏下，他們已經做得非常棒了。但是比起電子表格來說，它所用的交互模型毫無疑問是太有限了。為何現代的Web應用仍然有這么多的局限呢？造成目前的狀況有一些合理的技術原因，我們現在就來考察一下。 網絡延遲因特網的宏偉藍圖是將這個世界上所有的計算機都連接起來，形成一個無比巨大的計算資源。如果能把本地調用和遠程調用等同起來，那么無論是分析蛋白質的成分還是破解外太空的信號，使用者都無需考慮機器的物理位置，剩下來的只有愉快地計算。但是非常不幸，本地調用和遠程調用是完全不同的東西。在現有的技術水平之下，網絡通信仍然是一件代價高昂的事情（也就是說，通常很慢，而且并不可靠）。在沒有網絡調用的情況中，不同的方法和函數以及它們所操作的數據都位于相同的本地內存中（圖16），向方法內傳遞數據并且獲得方法的返回結果是非常直接的。而在有遠程調用的情況下，位于網絡兩端的通信雙方為了發送和接收數據在底層需要進行大量計算（圖17）。比起數據在線路上的往返，這些計算需要消耗更多的時間。傳輸一段二進制的數據，中間要經過很多環節的編碼和解碼、錯誤校驗、失敗重發、數據包拆分和重組，數據最終轉化為0和1表示的二進制信號，通過線路（或者無線連接）到達另外一方。在本地，調用函數的調用請求被編碼為一個對象，然后將這個對象序列化為一系列字節，最后使用應用層協議（通常是HTTP）通過物理傳輸介質（例如銅纜、光纖或者無線電波）將其發送出去。在 遠程機器上，對應用層協議解碼，將獲得的數據字節反序列化，創建一個請求對象的副本。然后對數據模型應用這個對象并生成一個響應對象。為了將響應對象傳遞 給本地的調用函數，所有的序列化、反序列化以及傳輸層的操作都要反向再來一次。最后，響應對象被傳遞給本地的調用函數。這個交互過程很復雜吧，幸好，它是可以自動完成的。盡管如此，執行遠程調用時，上述所有這些操作仍然會在內部執行。如果我們到處使用遠程調用，性能勢必會大受影響。這也就是說，遠程調用是不可能和本地調用一樣有效率的。更糟糕的是，網絡的不穩定更讓這種效率損失捉摸不定，難以預計。相比之下，運行在本地內存之中的本地調用，在這一點上無疑要有優勢得多。等等，說了半天的遠程調用，這和軟件的可用性有關系嗎？答案是，大有關系。一個成功的計算機用戶界面要能以最起碼的水平模擬我們在真實世界中的體驗。交互的基本規則之一就是，當我們推一下、刺一下或者捅一下某個東西的時候，它立刻就會響應。響應的時間只要稍微拖長一點點，就會使人困惑，分散其注意力，把關注點從手頭的任務轉移到用戶界面上。遠程調用橫穿整個網絡，需要執行大量的額外操作，它們往往會把系統拖慢，使用戶察覺到延遲。在桌面應用中，只有當可用性設計做得非常糟糕的時候，才會出現這種令用戶感覺充滿bug、反應遲鈍的用戶界面，但在網絡應用中，什么都不做就能得到大量這樣的界面。因為網絡延遲不可預測，這類界面問題往往都神出鬼沒，對應用響應的測試也難以開展。換句話說，網絡延遲是導致實際應用的交互性糟糕的一個普遍原因。 異步交互用戶界面的開發者對于網絡延遲只能做最壞的假設。簡單地說，就是要盡可能讓用戶界面與網絡活動無關。天才的程序員們早已發明了一種確實有效而且久經考驗的方案，來專門解決這一問題。先賣個關子，讓我們到現實世界中走一趟。在我每天早上必做的事中，很重要的一項是叫醒我的孩子去上學。我可以站在床邊把他們折騰醒，催著他們起床穿衣，但這是一種很耗費時間的方法，總要耗費我很多寶貴的早間時光我要叫醒孩子，看看窗外，往往會忽略了喂貓。孩子們起來之后會問我要早餐。就像服務器端的進程一樣，孩子們起床總是慢吞吞的。如果我遵循同步交互模式，就要等他們老半天。不過，只要他們嘟囔一句“我醒了”，我就可以先去干其他的事，需要時再回來看看他們。按 照計算機的術語，我需要做的就是為每個孩子在一個單獨的線程中建立一個異步進程。開始之后，孩子們會在他們的線程里自己起床，我這個父線程沒有必要同步傻 等，他們完事后會通知我（往往還會問我要吃的）。在他們醒來的過程中，我并不需要和他們交互，就當他們已經起來并自己穿好衣服了，因為我有理由相信他們很 快會這么做的（圖19）。對于任何用戶界面來說，這是一種沿用已久的實踐，即創建異步的線程，讓它在后臺處理那些需要計算很久的任務，這樣用戶可以繼續做其他的事情。當啟動這個線程的時候，有必要阻塞用戶的操作[4]，但是在可接受的很短時間之后，阻塞就會解除。因為存在網絡延遲，使用異步方式來處理任何耗時的遠程調用是一種很好的實踐。實際上，網絡延遲問題和相關的解決方案由來已久。在老的客戶/服 務器模式中，當設計不佳的客戶端程序碰上了高負載的服務器時，用戶界面就會出現讓人難以忍受的延遲。即便是在如今的因特網時代，當切換頁面時，如果瀏覽器 半天出不來東西，那么這種糟糕的情況很可能就是因為網絡延遲造成的。在現有技術條件下，我們暫時還沒有辦法消除網絡延遲，但是至少有一個對策，那就是采用 異步方式處理遠程調用，不是嗎？糟糕的是，對于Web開發人員而言這樣做存在一個難點：HTTP協 議是一個“請求—響應”模式的協議。也就是說，客戶端請求一個文檔，服務器要么返回這個文檔，要么告訴客戶端找不著文檔或者讓客戶端去另外一個地方找，還 可以告訴客戶端可以使用它的本地緩存，諸如此類。總而言之，“請求—響應”模式的協議是一種單向的通信協議。客戶端可以向服務器發起連接，但是服務器不可 以向客戶端發起連接。甚至，當客戶端下次發起通信請求時，健忘的服務器都記不起來這個客戶端是誰了（HTTP是無連接的）。多數Web開發者使用現代的編程語言，例如，Java、他們熟悉用戶會話（user session）的概念，這其實是應用服務器對于不能保持連接狀態的HTTP協議的一種補救措施。HTTP就其最初的設計目的來說表現得非常好，采用一些巧妙的處理，它能夠適應設計之初沒有考慮的場合。但是我們的這個異步回調方案中的關鍵特征是，客戶端會收到兩次通知，一次是在線程創建的時候，另一次是在線程結束的時候。標準的HTTP和傳統Web應用模型可不會提供這些。像Amazon那樣的傳統Web應用，是建造在頁面概念之上的。給用戶顯示一個文檔，上面包括各種鏈接和表單，用戶可進一步訪問更多的文檔。這種交互模式可以在很大的規模上支持復雜的數據集（就像Amazon和其他網站已經證明的那樣），它所提供的用戶體驗也足以滿足開展業務的需要。十年來，這種交互模式在我們對因特網商業應用的看法上打下了深深的烙印。界面友好的所見即所得（WYSIWYG）Web制作工具使得站點更容易被理解為一堆頁面。服務器端的Web框架使用狀態圖來對頁面的轉換建模。沒有引入，傳統的Web應用就這么一直牢牢地束縛在頁面刷新操作之上，就好像這種刷新是理所當然而且無可避免的，從沒有嘗試過任何異步的處理方案。當然，毫無疑問，傳統的Web應用肯定不是一無是處的。畢竟Amazon在這種交互模式上創造了成功的商業應用。但是這種適用于Amazon的方式并不一定適用于所有的人。為什么這么說呢？要理解這一點，我們需要考察用戶的使用模式（usage pattern）。 獨占或瞬態的使用模式泛泛地討論自行車和SUV（運 動型轎車）孰優孰劣毫無意義。因為它們各自都有優點和缺點——舒適度、速度、油耗或者個人身份的象征等等。只有在特定的使用模式下討論，這樣的比較才有意 義。例如，是要在上下班高峰時段穿越市中心，還是要帶上一家老小去度假，或者只是要找個躲雨的地方。在類似這樣的具體情況下，我們才能有的放矢地比較。對 于用戶界面，亦復如是。軟件可用性專家Alan Cooper寫了很多有關使用模式的好文章，他定義了兩種主要的使用方式：瞬態的（transient）和獨占的（sovereign）[5]。瞬態應用可能每天都會偶爾使用一下，但是總是作為次要的活動，突發性地用上一會兒。與之形成鮮明對比的是獨占應用，獨占應用需要應付用戶每天幾個小時的持續使用。很 多應用天生就具備獨占或者瞬態的性質。例如，寫作用的字處理軟件就是一個獨占應用，可能還會用到幾個瞬態的應用，比如文件管理（文件的開啟和關閉窗口中常 常會嵌入這個功能）、字典或者拼寫檢查工具（很多字處理程序也嵌入這些功能），還有與同事聯絡的電子郵件和聊天工具。而對于軟件開發者，文本編輯器、調試 器或者IDE（集成開發環境）則是獨占的。獨占應用常常使用得更頻繁。要知道，一個良好的用戶界面應該是不可見的。衡量使用頻繁程度的一個好的標尺，是當這個用戶界面發生明顯的停頓時，它對于用戶流程的影響。例如，從一個目錄向另一個目錄移動文件要發生2秒鐘的停頓，我能愉快地接受；可是如果這兩秒是發生在我正飽含激情地用繪畫軟件創作一幅作品時，或者是我正努力地調試一段很難對付的代碼時，這肯定會讓我感覺十分不爽。Amazon是一個瞬態應用，eBay、Google以及大多數大型的公眾Web應用都是瞬態應用。自因特網誕生之日起，專家們就曾經預測傳統的桌面應用面臨Web應用的沖擊。十年過去了，這些都還沒有發生，為什么呢？基于Web頁面的方案對于瞬態應用是足夠了，但是對于獨占應用卻還遠遠不夠。 忘掉Web現代Web瀏覽器和它最原始的出發點（從遠程服務器上獲得一個文檔）相比已經完全不是一碼事了，它們之間就像是瑞士軍刀和新石器時代的狩獵工具一樣，可謂是天壤之別。各種交互組件、腳本語言和插件，這些年來無法抑制地瘋狂發展，近乎強制地一次又一次地創造著新的瀏覽體驗。[。1993年的時候，Netscape創立之前的Marc Andreessen（Netscape的創始人）還在游說Tim BernersLee（Web的創始人，W3C的領導者）等人，列舉為HTML引入一個圖片標簽的好處]。幾年以前，一些先行者就已經開始把JavaScript當作一種嚴肅的編程語言來對待。但就整體而言，更多的人仍然把它和那些假模假樣的警告框以及“點擊猴子贏大獎”的廣告一類的小把戲聯系在一起。瀏覽器大戰導致JavaScript成了個被誤解的、病態的孩子，Ajax可以看作是他的康復中心[6]。只要適當引導，然后給它配上合適的框架，JavaScript就很有可能變成因特網的模范公民。它能真正增強Web應用的實用性，而且不強迫用戶安裝額外的軟件，或者逼迫用戶拋棄自己心愛的瀏覽器。得到廣泛理解的成熟的工具可以幫助我們達成這一目標。本書后面會大量提到的設計模式就是這樣一類工具。推 廣和普及一項新技術，既是技術事務，也是社會行為。一旦技術已經成熟，人們還需要領會應該如何去使用它。這一步驟常常是通過用它來做我們很熟悉的事情開始 的。比如，早年的自行車叫做“木馬輪”或者“蹬行馬”，靠腳使勁蹬地的反作用力來前進。隨著這一技術漸漸為大眾所接受，后來的發明者們會發明出這一技術新 的使用方式，給它加上踏板、剎車、鏈條齒輪以及充氣輪胎。每一次的發明創造，都使得自行車中馬的影子越來越淡，以至于徹底消失（圖110）。相同的過程也發生在如今的Web開發領域。Ajax背后的技術有能力將Web頁面轉換成某種完全不同的新東西。早期Ajax的使用嘗試使得Web頁面開始變得像“木馬輪”一樣不倫不類。要領悟Ajax的精髓，我們就要忘掉Web的頁面概念，也就是說，我們要打破這些年來所形成的經驗。就在Ajax正式命名后的這幾個月，這樣的事已經發生了不少。