首先，看看在使用struts等框架做開發的時候，遇到的一些問題：
1.從URL到Action B和S之間是HTTP，我們在http中能夠表達的僅僅是一個URL和若幹字符串格式的參數。於是在任何業務開發過程中，我們都少不瞭從前端的URL+參數到後端的業務方法之間的映射。這個事情是枯燥無味的，是沒有技術含量的，是可以被認為是體力活的–但卻是不得不做的。
2.請求一個展現數據的頁面，一定是先到Action，準備數據，然後forward到頁面，這與早期的jsp+javabean開發或者asp開發中是完全相反的，後者實際上是你請求某頁面，那麼你首先就是到達這個頁面，在這個頁面的處理過程中，再去做諸如準備數據這樣的事情。我認為後者這種方式才是更加自然的方式。
3.後端不知前端有什麼 一次請求從前臺提交到後臺的時候，應用服務器把HTTP請求包裝成request對象，並把所有的請求參數放在其中。於是，當後端接收到一個參數的時候，我們不知道這個參數在前端對應著什麼樣的html元素。這個問題在處理下拉框輸入的時候尤為突出。我們寫頁面的時候通過定義select下面的option元素告訴應用，說隻能選某幾個選項其中之一，然後為瞭確保數據正確，在後端我們還是要校驗用戶的輸入是否是那幾個選項中的一個。這相當於我們兩次告訴系統輸入的允許范圍。為什麼不能隻做一次呢。因為在以往的開發過程中，後端不知道前端有什麼。
4.無狀態的Action層 在以往的開發中，另外一個很重要的問題是關於狀態的。HTTP是無狀態的協議，於是基於HTTP的jsp、struts也都是無狀態的。什麼是無狀態呢，典型的表現就是，你第一次請求查詢出來的一條數據，在下一次請求的時候，一定已經找不到瞭（我們不可能把大多數如此普通的數據簡單的放到session/application作用域中去）。這代表著使用Hibernate的場景下，為瞭正確的更新一個對象，你需要在提交表單的時候再次查詢數據庫獲得這個對象，然後把用戶修改瞭的屬性Set到這個對象上，然後再保存之。同時，為瞭實現樂觀鎖定，你需要把version信息也放在表單上發送給客戶端–如果客戶端傳回給你一個虛假的非常高的版本號，那麼你的樂觀鎖形同虛設–兩個人同時打開某一條記錄，後提交的那個人完全可以在誰都不知情的情況下覆蓋前一個人的提交結果。
JSF/seam為我們解決瞭這些問題。基於JSF，我使用Spring替代瞭Seam，同樣能夠解決這些問題。
