JSF和Struts的區別概述
據說JSF的主要負責人就是struts的主要作者，所以JSF和Struts的相似點還是有很多的。
◆都采用taglib來處理表示層
◆都是采用一套標記庫來處理頁面的表示和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的配置，頁面導航等問題，增加了系統的靈活性。
◆都采用資源文件來處理國際化和本地化的問題。
然而，JSF和Struts的不同點也很多，下面分別說明：
1、首先JSF和Struts的側重點不同，Struts側重于控制層，側重于如何分派和處理用戶的請求，所以表示層的taglib功能不夠強大。而JSF則側重于表示層，實現了大量的標準組件，允許開發人員對表示層有更多的控制權，同時JSF實現了一個開放的架構，允許開發人員創建自己的組件，或者在現有的組件上繼承，開發功能更強大的組件。本人認為這是JSF***的一個特色。（有點類似于vcl和。net組件）
2、和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的實現問題。
3、關于數據驗證，Struts可以采用在FormBean中的驗證函數中進 行驗證，也可以使用validator進行驗證（關于這種驗證方法，本人沒有測試過，不知效果如何，希望有經驗的朋友指教！）。在JSF中，提供了一些標準的validator.可以對輸入的數據做一些簡單的驗證，例如驗證數值數據的范圍，字段是否必填等。但其驗證的反饋信息為英文。如果該信息不能自定義的化，那么針對國內的應用就不太適合了，目前本人還沒有找到該反饋信息是否能夠自定義的辦法。另外對于input類型的組件可以通過validator屬性關聯到backing bean的一個驗證方法上。在事件處理方法中進行驗證也是一個辦法。
在JSF中還有一個問題就是在JSF生成的頁面中，組件的Id命名比較怪異，所有的組件的id都類似于“form：compnentid”即form的名稱＋“：” ＋組件的id.這樣通過javascript訪問組件就不是很方便，通過form.id形式好像不能訪問到組件。不知道各位有沒有好的解決方案。
4、控制層：Struts 中通過form的action來提交請求，通過ActionServlet來分發請求，***由ActionBean來處理請求，在Action中實現業務邏輯或者調用其他的業務邏輯bean來完成用戶的請求并返回客戶端。在這里，一個form只有一個action，即一個頁面只能提交到一個action Bean.對于頁面上有多個按鈕都需要提交的情況就需要使用一些變通的方法了。和傳統的web開發的模式比較接近。
對于JSF，采用了事件模式來處理用戶提交的請求。JSF實現了事件監聽器來監測事件，例如當用戶單擊了一個按鈕就會觸發一個按鈕單擊事件，還有valuechange事件監聽器來監測數值改變的事件等。例如在頁面中通過通過CommandButton按鈕的action屬性來關聯到backing bean的方法來執行相應的操作。 每個不同的按鈕都可以關聯不同的方法，當然也可以關聯相同的方法（這樣就和Action Bean非常類似了）。這中開發模式比較接近于傳統的c/s模式或者Asp.net的開發模式。對于那些從c/s架構程序或者Asp.net架構轉過來的開發者來說，這種方式可能更自然一些。
在JSF的一些簡單的示例程序中，通常把和jsp對應的model層和jsp所提交的action放在 同一個backing bean中，即業務邏輯和業務邏輯所處理的數據在同一個bean中。本人認為，這樣的結構只能用在簡單的應用中，對于企業級的開發并不適合。應該將頁面所關聯的數據和頁面所做的action分開，這樣的結構更好一些，比較類似于struts的結構。
JSF的backing bean中的方法訪問session，request等沒有struts中的直觀。筆者找了很多例子才知道如何訪問session中的數據。
5、頁面的導航：關于頁面的導航，struts和JSF比較類似。都是在xml的配置文件中配置導航規則。每個要跳轉的頁面都有一個別名，在程序中通過別名進行跳轉。另外Struts中的跳轉是在ActionBean中發生，execute方法***返回一個actionForward來進行跳轉。而JSF則在事件處理方法中***返回一個字符串，由系統在xml文件中匹配自動進行跳轉。在JSF中也可以通過在JSP頁面的CommandButton的action 屬性中直接填寫跳轉的別名直接跳轉，而不必經過事件處理方法的處理。
6、資源文件的管理：Struts和JSF對于資源文件的管理比較類似，Struts中在struts-config.xml中對資源文件進行配置，實現整個程序的統一管理。而對于JSF則可以在每個JSP頁面中分別定義資源文件，然后通過資源文件的別名來訪問資源文件中的內容。兩者的格式也不相同，在 Struts中，格式為： grade1.grade2.grade3 = your information，通過“。”來表示級別。而在JSF中則必須通過下劃線來表示級別，例如grade1_grade2_grade3= your information.本人認為還是struts的方案更直觀一些。另外在Struts的資源文件中可以定義信息的顯示格式，例如： error.header，error.footer.而JSF中如何定義還不太清楚，或者可以通過定義Messages標記的屬性來定義。
【編輯推薦】
