表現層的Session狀態

　　當Session狀態保存在服務器端時，它使用一個Session ID得到，并且會一直保持住，直到發生以下的情形：

　　　. 一個預定義的Session超時發生了

　　　. Session被手動設置為無效

　　　. 狀態由Session中移除

　　要注重的是服務器關閉后，一些內存中的Session治理機制可能不能恢復。

　　很明顯，對于要保存大量Session狀態的應用，將它們的Session狀態放在服務器是更好的。當狀態被保存在服務器上時，你不會有客戶端Session治理的大小和類型限制。此外，還避免了由此帶來的安全問題，而且也不會碰到由于在每個請求間傳送Session狀態帶來的性能影響。

　　使用該方式，你可以更加靈活地作處理，并且便于擴展和提高性能。

　　假如你在服務器上保存Session狀態，你必須要決定如何使該狀態信息被每個服務器得到，即你運行該應用的服務器。假如群集的軟件是運行在負載均衡的硬件上，那么就要處理這個Session狀態的復制問題，這是一個多維的問題,不過，眾多的應用服務器現在都提供了各種各樣的解決方案。也就是說，在應用服務器的級別上有解決的方法。其中的一個方法是保證用戶只與一個服務器打交道，它在流量治理軟件上用得比較多，例如Resonate [Resonate]的軟件，在用戶的Session中，該用戶發出的每個請求都會被路由到同一個服務器處理。這種方式也被稱為server affinity。

　　另一個可選的方式是在商業層或者資源層保存Session狀態。企業javaBeans組件可用來在商業層保存Session的狀態，而一個關系數據庫則可用在資源層。

　　控制客戶訪問

　　有很多時候我們都要限制或者控制客戶端訪問某些應用資源。下面我們就來討論其中兩種這樣的情形。

　　限制或者控制客戶訪問的一個原因是防止一個視圖或者部分的視圖被一個客戶直接訪問。這個問題會發生在以下情況，例如僅有注冊或者登陸后的用戶才可答應訪問一個非凡的視圖，或者是根據用戶的角色限制用戶訪問部分的視圖。

　　在描述過這個問題后，我們將討論第二種情況，它和控制應用中一個用戶的流程有關。后者的討論和重復的form提交有關，因為多次提交將會導致不必要的重復事務。

　　控制視圖訪問

　　在一些情況下，資源被限制為完全不答應某些用戶訪問。有幾個方法可以做到這一點。一個方法是加入應用邏輯到處理控制器或者視圖的程序中，禁止某些用戶訪問。另一個方案是設置運行時的系統，對于一些資源，僅答應經由另一個應用資源內部調用。在這種情形，對于這些資源的訪問必須被通過另一個表現層的應用資源進行，例如一個servlet控制器。對于這些受限制的資源不答應通過一個瀏覽器直接調用。

　　處理這個問題的一個常見方法是使用一個控制器來作為該類訪問控制的一個委托者。另一個常見的方式是在一個視圖中置入一個保護設置。我們這里主要討論基于視圖的控制策略。在考慮選擇何種方式來控制訪問之前，我們首先來描述一下這些策略。

　　在視圖中置入保護邏輯

　　對于在一個視圖的處理中置入一個保護邏輯，有兩個常見的應用。一個是防止訪問整個的資源，而另一個是限制訪問部分的資源。

　　在每個視圖中包含一個All-or-Nothing保護

　　在一些情況下，置入到視圖處理代碼中的邏輯以all-or-nothing的模式答應或者拒絕訪問。也就是說，這個邏輯限制某個非凡的用戶訪問一個非凡的視圖。通常這一類型的保護最好封裝到一個中心化的控制器中，這樣便于集中化治理。假如只有很少的頁面需要防護，那么可以使用這個策略。通常這個情形都是發生在一個非技術人員需要更新網站一小部分的靜態文件。假如客戶仍然需要登陸到網站來瀏覽這些頁面，那么只需要在每個頁面的頂部加入一個自定義的tag（標記）就可以做到控制訪問。如3.1的例子所示。

　　例子3.1 在每個視圖中包含一個All-or-Nothing保護