本文羅列一些問題，都是平常開發中經常遇到的，希望對你們有所幫助。
1.資料校驗
顯然，正常的j2ee程式，都離不開資料校驗這一塊。而資料校驗又分為客戶端校驗和伺服器端校驗。客戶端校驗的好處是使用者體驗好，輸入東西以後，可以馬上得到響應，而不需要聯網，伺服器的壓力也小一些。但是客戶端校驗面臨著跨瀏覽器的挑戰，設定瀏覽器的公升級也會給應用程式帶來麻煩，當然，乙個稍微懂點js的人，可以輕鬆跳過客戶端的資料校驗。伺服器端得資料校驗就穩健的多了，但是對系統的開銷也就多一些。就像你去買伺服器，ibm的當然好了，但是也貴啊！有人建議資料校驗都放在伺服器端，他真的是有錢……
資料校驗到底放在哪邊，或者兩邊都進行校驗？這個需要根據專案的特點來選擇，甚至是頁面資料的重要性來選擇。當然，乙個比較好的辦法就是不進行資料校驗——採用選擇框等資料輸入方式，限制使用者的輸入，就不需要資料校驗了。
2.防止重複的客戶請求
有時候，使用者會不經意的重複提交資料，這在電子商務等資料提交要求很高的領域，會產生比較嚴重的後果。比如你乙個訂單提交了兩次，但你的本意只想買乙個商品……
這個時候，最好的處理方式是明確的重新整理會話，在頁面處理完成之前，先更新會話。這樣會話仍然可用，並且可以在伺服器端檢查會話的有效性。
3.維護會話狀態
客戶端技術有：在html中使用隱藏表單，使用cookie，url重寫。
1.隱藏表單技術簡單，好用。在會話狀態使用不是特別多的專案中，比較合適使用。但是如果會話技術要求很高的專案，那麼隱藏表單就會大量的，重複的在每個頁面出現，這樣會給效率帶來不利。其次，由於隱藏表單是明文(一檢視頁面原始碼就可以看到)，如果會話資訊敏感，甚至還需要加密。
2.重寫url，這種方式在非表單提交時，非常有用。但是它也不能避免隱藏表單方式所擁有的缺陷。
3.cookie技術：這種技術我個人比較排斥，這裡就不寫了。
綜上，客戶端保持會話狀態這種方式，是輕量級的，不可靠的。
4.jsp的作用
jsp在j2ee技術體系中，其實感覺起來就比較尷尬，它做的事情，servlet完全可以做，而jsp基本上又可以替代servlet。現在大部分程式設計師都可以做到把servlet作為非檢視層，但是很多程式設計師不能做到把jsp純作為檢視。乙個良好的實現應該是jsp只作為顯示使用，而沒有其他。這樣的好處是分層合理，便於維護。
5.css的使用
為了程式介面的統一和高效，採用css是一種非常高效的方式，在所謂的***使用者介面android，iphone的ui中，也使用了類似css的概念。
6.ejb的設計
大家都知道ejb是來處理業務邏輯的，但是ejb的設計卻不是每個人都把握的好。舉乙個簡單的例子，比如乙個使用者提交了購物請求，後台必須先判斷使用者的信譽，然後才決定是否生成訂單。那麼，這樣的功能是否應該設計在乙個ejb中呢？乙個好的設計原則是低耦合，高內聚。如果信譽判斷和訂單功能在其他地方不再使用，那麼，這些步驟寫在乙個ejb裡面是比較合理的。但是如果這兩個功能在其他地方也有使用，那麼，設計三個ejb是合理的：乙個完成信譽判斷，乙個完成訂單功能，乙個完成控制器，耦合器的角色。
7.ejb層和web層的資料互動
不少人想當然的認為，在兩層之間互動資訊，大量資料的時候，使用物件型別，少量資料的時候，使用簡單型別。其實在高併發量的企業應用中，使用物件型別在這兩層之間互動可以減少網路壓力，並且讓資料之間更有關聯。
8.ejb效能
大部分j2ee應用，出現效能瓶頸的地方都是ejb層，因為ejb層可能進行大量的網路通訊，這嚴重的降低了ejb層的功效，最佳處理方式是把需要和ejb頻繁通訊的元件和ejb放在一台伺服器上。
J2ee技術難點
session cookie區別聯絡 jsp servlet區別聯絡 filter執行流程 opensessioninview原理 clone與servilizable區別聯絡 equals與hashcode聯絡 1 瀏覽器禁用cookie後,session還能工作嗎?可以說對和不對，需要解釋 不能...
J2EE 類的建立
1.建立book類 package j2eetest 包名 author wanjinyoung public class book 獲取書名 public string getname 獲取作者 public string getauthor 獲取編號 public string getisbn ...
J2EE中的路徑問題
解決方案 採用絕對路徑，但為了解決不同部署方式的差別，在所有非 struts 標籤的路徑前加 如原路徑為 images title.gif 改為 images title.gif 的作用是取出部署的應用程式名，這樣不管如何部署，所用路徑都是正確的。缺點 操作不便，其他工具無法正確解釋 採用相對路徑，...