選擇JSF不選Struts的十大理由

我的一個客戶不知道該選用Struts還是JSF。就像你預料的那樣，我通常會問：這2中框架之間有什麼區別？當然，除了我的這個客戶外很多人都面臨這樣的選擇。

總的來說，我建議在新專案中優先考慮JSF。雖然常常有一些商業上的因素迫使我們為現有的專案選擇了Struts，而且那些解決方案還有待考驗，但是，讓我們面對一個事實：JSF比Struts好多了。

下面是我選擇JSF而不選Struts的十大理由：

1.Components(元件)

2.Render Kits

3.Renderers

4.Value Binding Expressions（值繫結表示式）

5.Event Model（事件模型）

6.Extensibility(可擴充套件性)

7.Managed Beans(Dependency Injection 依賴注入)

8.POJO Action Methods

9.JSF is the standard Java-based web app framework (JSF是java web應用程式的標準框架)

10.There's only one Struts(只有一個Struts)

10.There's only one Struts(只有一個Struts)

Struts是一個開源產品，然而JSF是一個標準。這個細節常常被新的JSF學習者忽略，其實這是顯而易見的，因為我們有多個JSF的實現。雖然JSF還很不成熟，但是我們已經有了2個優秀的JSF實現可以選擇：Sun的參考實現和Apache的MyFaces。另一方面，我們只有一個Struts。

9.JSF is the standard(JSF是標準)

JEE 5.0要提供一個JSF的實現，這表明JSF不久將會無處不在。這可能與你無關，但是和工具供應商密切相關。現在大概有50個java web應用程式框架，工具供應商不會情願去支援一個特別的框架，但是他們會毫不猶豫的去支援一個標準。而且不止供應商，開源專案也會迅速的聚集在JSF的四周，爭先恐後的去實現相同的功能。比如說，直到我們去實現本質上和Shale的Tapestry差不多的檢視的時候，我才知道Facalets。（從長遠來看，我相信這種冗餘是件好事，會給我們帶來好處）

8.POJO Action Methods

Struts的行為是和Struts的API繫結在一起的，但是JSF的行為方法可以在POJPO中實現。這意味著你不用在表單和模型物件之間實現一個多餘的行為層。順便說一下，在JSF裡面沒有行為物件，行為在模型物件中實現。但是也請注意一點：如果你願意你也可以生成與JSF獨立的行為物件。在Struts裡面，你有Form. Bean和Action Bean。Form. Bean包含資料而Action Bean包含邏輯。OO狂會想去合併前2者，在Struts你辦不到。但是在JSF中，你可以分開資料和邏輯，也可以合併到一個物件中，一切由你決定。

7.Managed Beans(Dependency Injection 依賴注入)

和Spring一樣，JSF也使用了依賴注入（DJ）（或控制反轉（IoC））去例項化和初始化Bean。Struts的確為你生成了Form. Bean和Action Bean，但是JSF可以為你生成各種各樣的Managed Bean。

6.Extensibility(可擴充套件性)

這個很重要。JSF有6個物件實現了這個框架的大部分功能，而且你可以很容易的用你自己的實現代替原有實現。比如你想加一個自定義引數在JSF表示式語言裡面，或是新增一個自己的檢視控制器以便於區分元件和HTML。事實上Shale實現了上面的功能。如果你還沒有滿足，JSF提供了幾個地方你可以輕鬆的控制JSF的生命週期。Shale給你的會更多。

5.Event Model（事件模型）

JSF的事件模型使你可以對值改變，動作，JSF生命週期階段變換等作出反應。在JSF1.1中，那些事件都是在伺服器端處理的，這肯定是一個缺陷，好在JSF2.0計劃支援客戶端事件，拭目以待吧。

4.Value Binding Expressions（值繫結表示式）

在Struts中，你負責把資料從Form傳遞到模型物件。你實現的Action的execute方法是把Form作為一個引數。然後你再手動的把資料從Form. Bean裡面取出放到模型物件裡面。你要為應用裡面的每個Form做這些事情，然而在JSF裡面，你只需像這樣：#{model.property} 就夠了，其他的交給JSF來處理。

3.Renderers

你有看過Struts的標籤的原始碼嗎？它直接生成HTML。JSF元件標籤什麼都不生成，它和伺服器上的一對component-renderer對應。Component維護元件狀態，rendered負責獲得檢視。重點是renderers是可插拔的，即你可以根據自己需求實現然後替代掉預設實現。比如說我在NFJS上面的Felix談話中舉例說明了怎麼去實現一個自定義的label renderer。你只需要配置你的renderer，JSF就會自動在你的應用程式裡面使用他。

2.Render Kits

在幾年前我曾經有份Struts諮詢工作，我們必須同時支援瀏覽器和無線裝置，非常痛苦。但是用JSF來完成那個任務非常容易，因為你可以生成你自己的render kit－為一種特定顯示技術的renderers的集合－然後配置到JSF裡面。

1.Components(元件)

元件是Struts和JSF之間最大的區別。就像Swing一樣，JSF提供豐富的底層構件去開發元件然後新增到標準的元件集。那些底層構件讓你很容易的生成自己的元件並且和別人共享。現在我們到處都能看到自定義元件跳出來，比如說Oracle的ADF和MyFaces，兩者都提供了豐富的元件集，就像javascript日曆，tree等等。當然，元件只是一部分。典型的是，元件都和一個獨立的renderer對應，這給我們帶來了真正的好處（看第3條）。但是和JSF中的很多東西一樣，你不一定要墨守成規。只要你願意，你可以實現render自己的元件，雖然這樣你會失去給元件加入別的renderer的能力。