J2EE表現層設計思考核心是什麼?下面yjbys小編為大家分享最新J2EE表現層設計解讀，希望對大家學習J2EE有所幫助!
設計表現層時需要考慮的幾個問題
開發者在設計表現層時，可以使用不同的模型，這時需要考慮一些相關的設計問題。這些問題和模型關係的緊密程度也各有不同，它們可以影響系統的各個方面，包括有安全、數據完整性、可管理性和擴展性。雖然這些設計問題大部分都可以用模型的形式表示，但我們不打算這樣做，因為這樣更為抽象，我們選擇以非正式的文檔形式表示。我們只是根據不同的模型，將每個需要考慮的問題列出來。
Session管理
用户Session指的是跨越一個客户和服務器多個請求間的一個對話。我們將在以下部分根據用户Session的概念討論這個問題。
客户端的Session狀態
在客户端保存Session的狀態指的是將Session的狀態串行化並且嵌入到返回給客户的HTML頁面中。
在客户端保存Session的狀態有這以下的好處：
. 它實現起來相對容易
. 在保存少量的狀態信息時，它工作得很好
此外，這個策略還消除了跨越多個服務器複製狀態的問題，例如多個服務器間實現負載均衡時就會遇到這種情況。
在客户端保存Session狀態通常有兩個方法HTML的隱藏字段和HTTP cookies我們將在下面討論這些策略。第三個策略則是在每個頁面的URL中嵌入Session狀態信息。
雖然第三個方法比較少見，但它也有着其它兩個方法的許多限制。
HTML的隱藏字段(HTML Hidden Fields)
雖然這個方法實現起來相對容易，不過使用HTML隱藏字段在客户端保存Session狀態仍然有着許多的缺點。這些缺點在保存大量的狀態時尤為突出。保存大量的狀態將會對性能有很大的影響。因為每次發出請求和響應時，都需要在網絡中傳送這些狀態信息。
此外，當你利用隱藏的字段來保存Session狀態時，這些持久的狀態值只能是字符串值，因此所有的對象引用都必須被“字符串化”，而這些信息除非經過特別的加密，否則都是以明文的形式顯示在HTML的源代碼中。
HTTP Cookies
與隱藏字段的方法一樣，使用HTTP Cookies的方式也是相對簡單的。不幸的是，這兩個方法有着許多相同的缺點。特別是，在保存大量的狀態信息時將會對性能產生很大的影響，因為在每次的請求和響應時，都必須在網絡上傳送全部的Session狀態信息。
在客户端保存Session狀態時，我們也會遇到大小和類型的侷限問題。cookie headers的大小是有限制的，這樣就限制了可以被持久保存的數據量，而且和隱藏字段的方法一樣，當你使用cookies來保存Session狀態時，這些持久的狀態信息只能使用字符串值。
在客户端保存Session狀態會帶來的安全問題
當你在客户端保存Session狀態時，你必須考慮到由此帶來的安全問題。如果你不想數據暴露給客户端，你就需要一些方法來加密數據，從而保證數據的安全。
雖然在客户端保存Session狀態相對容易實現，不過它有着很多的缺點，這些都要我們花費時間去解決。對於需要處理大量數據的項目，特別是企業的系統，使用這種方式是得不償失的。
表現層的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保護
＜%@ taglib uri="/WEB-INF/" prefix="corePatterns" %＞ ＜corePatterns:guard/＞ ＜HTML＞ . . . ＜/HTML＞給視圖的某些部分加入保護
在其它情況下，置入到視圖處理代碼的邏輯可拒絕一個視圖的某些部分。這個策略可以和上面的all-or-nothing策略一起使用。為説明這一點，我們這裏使用控制一個建築物中的一個房間作類比。all-or-nothing的`保護策略告訴用户是否可以進入房間，而第二個保護策略則是告訴用户在進入房間後，允許他們看到什麼東西。以下就是一些你可以利用這個策略的例子。
根據用户的角色決定是否顯示視圖的某些部分
根據用户的角色，視圖的某部分可能不顯示。例如，一個經理在收看管理信息時，他可以到其員工的子視圖，而作為一個員工，他只可以看到自己組織的信息，而不可以其它信息，如例子3.2所示。
例子3.2 根據用户的角色，部分的視圖不顯示
＜%@ taglib uri="/WEB-INF/" prefix="corePatterns" %＞ ＜HTML＞ ＜corePatterns:guard role="manager"＞ ＜b＞This should be seen only by managers!＜/b＞ ＜corePatterns:guard/＞ ＜/HTML＞This should be seen only by managers!
根據系統的狀態或者錯誤情形不顯示部分的視圖
根據系統的環境，顯示的規劃可以被修改。例如，如果用户使用的是一個單CPU的硬件設備，那麼使用多個CPU的部分設備就可以不顯示。
根據配置控制資源
要限制某個客户直接一個特別的視圖，你可以配置表現層只有通過內部的資源才可以到這些資源，例如一個使用RequestDispatcher的servlet控制器。此外，你還可以使用Web容器中內置
的安全技術，根據servlet2.2或者以後的規範。安全限制被定義在稱為的配置描述文件中(deployment descriptor)。
basic和form-based的認證方法在Servlet規範中也有描述。在此我們不打算重複這個規範，你可以到以下網址去查看當前規範的細節()。
你已經明白了加入安全限制到你的應用時會有什麼用處，我們簡要討論了這個問題並且介紹瞭如何通過配置令它和all-or-nothing保護相關。最後，我們描述了一個簡單和常用的方法作為all-or-nothing保護，以限制一個資源的。
通過安全限制保護資源
應用或許被配置在一個安全限制中，而這個安全限制允許使用編程的方法根據用户的角色來控制。資源可以被某些角色的用户，並且禁止其它的角色。另外，某個視圖的一部分也可以根據用户的角色來限制。
