據說JSF的主要負責人就是struts的主要作者所以二者的相似點還是有很多的
都采用taglib來處理表示層在jsp頁面中二者都是采用一套標記庫來處理頁面的表示和model層的交互
二者都采用了bean來作為和jsp頁面對應的model層該model層保存了jsp頁面上的數據同時可以作一些驗證工作在struts中就是FormBean在JSF中就是back bean
都采用bean作為控制層Struts中采用ActionBean來處理業務邏輯對於簡單的應用可以直接在ActionBean中編寫業務邏輯代碼也可以調用另外的bean或者EJB來處理業務邏輯對於JSF則采用backing bean來處理業務邏輯同樣backing bean也可以直接編寫業務邏輯或者調用其他的bean來處理業務邏輯
都采用xml配置文件來處理bean的配置頁面導航等問題增加了系統的靈活性
都采用資源文件來處理國際化和本地化的問題
然而二者的不同點也很多下面分別說明
首先二者的側重點不同Struts側重於控制層側重於如何分派和處理用戶的請求所以表示層的taglib功能不夠強大而JSF則側重於表示層實現 了大量的標准組件允許開發人員對表示層有更多的控制權同時JSF實現了一個開放的架構允許開發人員創建自己的組件或者在現有的組件上繼承開發功 能更強大的組件本人認為這是JSF最大的一個特色（有點類似於vcl和net組件）
和jsp 對應的model層在Struts中采用FormBean來保存用戶輸入的數據基本上一般字段的類型都是String而且可以進行簡單的驗證當然 如果采用動態的FormBean就不能在FormBean中進行驗證了在Struts中jsp和FormBean是緊密結合在一起的只要寫一個 jsp就必須對應一個FormBean同時jsp上的每個組件都對應FormBean中相同名字的字段本人認為這裡不太靈活比如開發頁面的時候就 必須考慮後台的FormBean的實現但此時如果該頁面沒有FormBean的化則程序運行時會出錯在JSF中JSP頁面中的組件通過value屬 性和backing bean的字段關聯這樣就有比較大的靈活性頁面上的每個組件可以對應相同的backing bean也可以對應不同的backing bean（當然本人認為在一般的應用中一個頁面上的組件還是都對應到一個backing bean較好）而且在設計頁面的時候可以不考慮backing bean如何設計可以在設計完頁面之後再考慮backing bean的實現問題
關於數據驗證Struts可以采用在FormBean中的驗證函數中進 行驗證也可以使用validator進行驗證（關於這種驗證方法本人沒有測試過不知效果如何希望有經驗的朋友指教！）在JSF中提供了一些標 准的validator可以對輸入的數據做一些簡單的驗證例如驗證數值數據的范圍字段是否必填等但其驗證的反饋信息為英文如果該信息不能自定義 的化那麼針對國內的應用就不太適合了目前本人還沒有找到該反饋信息是否能夠自定義的辦法另外對於input類型的組件可以通過validator屬 性關聯到backing bean的一個驗證方法上在事件處理方法中進行驗證也是一個辦法
在JSF中還有一個問題就是在JSF生成的頁面 中組件的Id命名比較怪異所有的組件的id都類似於formcompnentid即form的名稱＋ ＋組件的id這樣通過javascript訪問組件就不是很方便通過formid形式好像不能訪問到組件不知道各位有沒有好的解決方案
控制層Struts 中通過form的action來提交請求通過ActionServlet來分發請求最後由ActionBean來處理請求在Action中實現業務 邏輯或者調用其他的業務邏輯bean來完成用戶的請求並返回客戶端在這裡一個form只有一個action即一個頁面只能提交到一個action Bean對於頁面上有多個按鈕都需要提交的情況就需要使用一些變通的方法了和傳統的web開發的模式比較接近
對於JSF采用了事件模 式來處理用戶提交的請求JSF實現了事件監聽器來監測事件例如當用戶單擊了一個按鈕就會觸發一個按鈕單擊事件還有valuechange事件監聽器 來監測數值改變的事件等例如在頁面中通過通過CommandButton按鈕的action屬性來關聯到backing bean的方法來執行相應的操作 每個不同的按鈕都可以關聯不同的方法當然也可以關聯相同的方法（這樣就和Action Bean非常類似了）這中開發模式比較接近於傳統的c/s模式或者的開發模式對於那些從c/s架構程序或者架構轉過來的 開發者來說這種方式可能更自然一些
在JSF的一些簡單的示例程序中通常把和jsp對應的model層和jsp所提交的action放在 同一個backing bean中即業務邏輯和業務邏輯所處理的數據在同一個bean中本人認為這樣的結構只能用在簡單的應用中對於企業級的開發並不適合應該將頁面所 關聯的數據和頁面所做的action分開這樣的結構更好一些比較類似於struts的結構
JSF的backing bean中的方法訪問sessionrequest等沒有struts中的直觀筆者找了很多例子才知道如何訪問session中的數據
頁面的導航關於頁面的導航struts和JSF比較類似都是在xml的配置文件中配置導航規則每個要跳轉的頁面都有一個別名在程序中通過別名進行 跳轉另外Struts中的跳轉是在ActionBean中發生execute方法最後返回一個actionForward來進行跳轉而JSF則在事 件處理方法中最後返回一個字符串由系統在xml文件中匹配自動進行跳轉在JSF中也可以通過在JSP頁面的CommandButton的action 屬性中直接填寫跳轉的別名直接跳轉而不必經過事件處理方法的處理
資源文件的管理Struts和JSF對於資源文件的管理比較類似Struts中在strutsconfigxml中對資源文件進行配置實現整個程 序的統一管理而對於JSF則可以在每個JSP頁面中分別定義資源文件然後通過資源文件的別名來訪問資源文件中的內容兩者的格式也不相同在 Struts中格式為 gradegradegrade = your information通過來表示級別而在JSF中則必須通過下劃線來表示級別例如grade_grade_grade= your information本人認為還是struts的方案更直觀一些另外在Struts的資源文件中可以定義信息的顯示格式例如 errorheadererrorfooter而JSF中如何定義還不太清楚或者可以通過定義Messages標記的屬性來定義
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28762.html
