JSF相对于Struts的一些优点(中英文版)

Top Ten Reasons to Prefer JSF over Struts
I've got a client who's trying to decide whether to use Struts or JSF. As you might expect, I'm often asked, especially at NFJS symposiums, what the differences are between the two frameworks. And, of course, my client's not alone; quite a few folks are trying to decide which framework to select. 
In general, my advice is to prefer JSF for new projects. There are sometimes compelling business reasons to stay on the Struts path for existing projects and those situations usually call for some close analysis, but let's face it: JSF is much better than Struts. 

So, without further ado, here's my top-10 list of reasons to prefer JSF to Struts... 

Top Ten Reasons to Prefer JSF to 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 
   
10. There's only one Struts 

#10: There's only one Struts 
Struts is an open-source product, whereas JSF is a specification. That's a subtle distinction, which is often lost on JSF newcomers, but it's significant because we can have numerous JSF implementations. As young as JSF is, we already have two excellent JSF implementations to choose from: the Reference Implementation from Sun and MyFaces, from Apache. On the other hand, there's only one Struts. 

#9: JSF is the standard

JEE 5.0 containers must provide an implementation of JSF, which means that JSF will soon be ubiquitous. That might not matter to you, but it matters to tool vendors. With approximately 50 Java-based web app frameworks, tool vendors have been reluctant to support a particular framework, but a standard is something tool vendors can, and have, rally(ied) behind. But it's not just vendors: open source projects are rallying around JSF with such dizzying speed that they're stepping over one another to implement the same features. For example, I hadn't even heard of Facelets until we were done implementing essentially the same functionality with Shale's Tapestry-like views. (I believe that redundancy is a good thing and will serve us well in the long run) 
#8: POJO Action Methods

Struts actions are tied to the Struts API, but JSF action methods can be implemented in Plain Old Java Objects. That means you don't have to implement an additional layer of actions that mediate between your forms and your model objects. btw, notice the careful wording of this item: there are no action objects in JSF because actions are typically implemented in model objects. But also note the careful wording of that last sentence: you can certainly create separate action objects if you want with JSF. Also with Struts, you have a form bean and an action bean. The form bean contains data and the action bean contains logic. OO purists want to put them together, but you can't with Struts. In JSF, you can spread out your data and logic, or put them in one object. The choice is yours. 
#7: Managed Beans

Like Spring, JSF uses dependency injection (or inversion of control, if you will), for instantiating and initializing beans. It's true that Struts creates action beans and form beans for you, but JSF generalizes that concept and adds the ability to initialize managed beans?of any type?created by the framework. 
#6: Extensibility

This is huge. JSF has 6 objects that implement much of the framework's capabilities and you can easily replace those objects by decorating the default implementations. That makes it ridiculously easy, for example, to add your own custom variables to the JSF expression language. It also makes it easy, for example, to plug in your own view handlers, perhaps a view handler that implements Tapestry-like views so you can truly separate components and HTML. In fact, Shale, does both of those things. As if that weren't enough, JSF gives you numerous hooks into the JSF lifecycle to inject your own voodoo. Shale gives you even more. 
#5: Event Model

JSF has an event model that lets you react to value changes, actions, and phase changes in the JSF lifecycle. In JSF 1.1, those events are handled entirely on the server, a sore point to be sure, but JSF 2.0 plans on supporting client-side events as well. Stay tuned. 
#4: Value Bindings

With Struts, you are responsible for ferrying data from your forms to your model objects. You implement an action with an execute method that takes a form bean as an argument. Then you manually pull data out of that form bean and push it to your model. For every form in your application. Ugh. With JSF, you do this: #{model.property}. That's all. JSF takes care of the rest. 
#3: Renderers

Have you ever looked at the source code for Struts tags? They generate HTML directly. JSF component tags, OTOH, don't generate anything; instead, they refer to a component-renderer pair on the server. The component maintains state whereas the renderer is in charge of rendering a view. The point here is that renderers are pluggable: you can replace the default renderers with your own implementations; for example, in my Felix talk at NFJS, I illustrate how to implement a custom label renderer that adds asteriks to labels that represent required fields. You plug in that renderer, and JSF will automatically use it throughout your application. Sweet. 
#2: Render Kits

I had a Struts consulting job a few years ago where we had to support both a browser-based interface and radio frequency devices, and it was painful. That task would've been greatly simplified with JSF because you can create your own render kit?a collection of renderers for a particular display technology?and plug it into JSF. 
#1: Components

Components are the number one differentiator between Struts and JSF. Like Swing, JSF provides a rich infrastructure for developing components in addition to a standard set of components. That infrastructure makes it relatively easy to create your own components and share them with others. Already, we're seeing custom components popping up all over the place, for example with Oracle's ADF and MyFaces, both of which provide a rich set of components such as JavaScript-powered calendars, trees, etc. Of course, components are only half the story; typically, components delegate rendering to a separate renderer, which provides substantial benefits (see item #3 above). But, as with most things in JSF, you are not forced to adhere to the party line. If you want, you can implement components that render themselves, although if you do so, you will loose the ability to plug a different renderer into your component. 
Your liver pays dearly now
For youthful magic moments
But rock on completely with some brand new components

rock'n'roll lifestyle
from motorcade of generosity by Cake
 
Trackback URL: http://jroller.com/trackback/dgeary/Weblog/top_ten_reasons_to_prefer 

 

总的来说，我建议在新项目中优先考虑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)

Struts是一个开源产品，然而JSF是一个标准。这个细节常常被新的JSF学习者忽略，其实这是显而易见的，因为我们有多个JSF的实现。虽然JSF还很不成熟，但是我们已经有了2个优秀的JSF实现可以选择：Sun的参考实现和Apache的MyFaces。另一方面，我们只有一个Struts。

9.JSF is the standard(JSF是标准)

J2EE5.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的能力。

(T117)