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保護，以限制一個資源的。
通過安全限制保護資源
應用或許被配置在一個安全限制中，而這個安全限制允許使用程式設計的方法根據使用者的角色來控制。資源可以被某些角色的使用者，並且禁止其它的角色。另外，某個檢視的一部分也可以根據使用者的角色來限制。
