Jakara Struts 編程 讀書筆記(1)（章節：1－2）

    書桌上擺著一本一年前就已經買好的書。 從來就沒覺得web技術有多複雜，無非是架構在http協議上的一種使用者和伺服器之間互動的技術而已，不過最近拿起來這本書看了看，才發現這裡面還是講了不少好東西，不僅僅是web上的，還有一些討論設計架構的知識。

    言歸正傳，書中的第一章簡單的介紹了web相關的一些常識。包括當年為了使用web技術不得不編寫CGI而且還要讓系統對每一個http請求都開一個重量級進程來應對（其實這到也沒什麼，你去看看apache httpd的應對方式，發現它現在還在為每一個請求開進程呢，原因很簡單，安全啊，一個請求失敗至少不會影響到全域）；包括Java Servlet應運而生是天選之子（說出來這句話，PHP笑了，獰笑的那種）。其中裡面比較有意思的是他在第15頁提到了JSP Model1 和 JSP Model2 這兩種編程範式，這本身沒什麼了，但是對於我這樣的初入web的人來說，倒算是在大腦中形成了第一個比較“系統”的概念，用JSP寫程式，就應該按照這兩種規矩來寫。這兩種模式的圖片如下：

    其中的JSP Model2 所利用的就是傳說中的MVC模式了（一談到設計模式就兩眼爍爍放光）。而在Struts構架中，Model 就是 ActionForm以及下面的類擴充，View就是JSP，而所謂的C，自然就是交給Action下面的擴充群（不知道現在寫這些話早不早）。

    翻到第二章，這裡面講了幾個問題我比較感興趣的（學過的就當複習了）：

1. HTTP請求和響應：HTTP協議的基本模型，這也是HTTP協議本身是stateless的最大原因，普通C/S程式在給資料庫程式提交請求的時候，因為請求處理的代碼是在用戶端運行，所以我們可以在用戶端後台起一個查詢線程然後等待線程結束，讓線程主動通知主程式更新結束，讓主程式做下一個動作；而B/S程式就慘了，這條路走不通，因為類似的資料庫更新動作是在伺服器端進行的，而基於HTTP的伺服器是不會給瀏覽器發送什麼請求或者通知一類的東西（除非這個更新動作在一個請求/應答流程中進行）。所以沒有辦法，瀏覽器只好週期性去查詢服務器端，所請求的更新是不是已經做好，如果做好，就從伺服器拉回來結果更新畫面，如果沒更新好（嘿嘿），那就只好繼續等待了，這算是web程式劣於C/S的地方。哦，對了，B/S這樣的取得結果的方式書中也起了一個名字－－pull approach。
2. 範圍：Struts（準確的說應該是Servlet/JSP標準）有幾個範圍可以用於不同層級的資料共用。這是很重要的資訊：

• 請求範圍：生存在一個HTTP請求/應答的周期中，可以用於web響應一次請求中的資料共用，所以這個共用域在一次請求結束時裡面的屬性是不是被刪除掉了並不重要（反正一次應答以後這個範圍就失效了）。
• 會話範圍（Session）：我們經常可以看到很多web網站在我們登陸一次以後就好像記住了我們一樣，無論我們跳轉到哪個頁面，該網站都好像認得我們一樣。通常，這種記住使用者資訊的行為都是通過會話範圍完成的。至於原理，去想想Session id 和cookie以及url rewrite技術就知道了。
• 應用範圍（Context）：這可以說是共用層級最高的範圍，通常一個web應用啟動的時候，其設定檔（自訂）的資訊都需要儲存在這個層次中，所以除了必須要將屬性（Attribute）放在裡面，否則輕易不要動這個範圍。

轉寄和重新導向：這兩個動作從結果來看雖然相似，但是web和瀏覽器的互動動作完全不同。如下：

• 轉寄：瀏覽器發出請求－>伺服器處理請求－>伺服器完成轉寄－>伺服器返回結果－>瀏覽器接受結果。
• 重新導向：瀏覽器發出請求－>伺服器處理請求－>伺服器返回給瀏覽器302並且給出重新導向串連－>瀏覽器重新用新串連發出新的請求－>伺服器處理新請求並返回結果－>瀏覽器處理結果。

可見，重新導向給了瀏覽器在處理頁面跳轉時一個處理機會，但是加多了瀏覽器和伺服器的互動。而重新導向則是簡化了這樣的關係但是瀏覽器就只能看到最終結果，至於那種更加適合就要看具體的需求了。而在這本書中，說的是轉寄比重新導向好，而轉寄是Struts的預設行為。