JSF跟Struts的优劣之争已经好久了。相对于Struts，本人更看好JSF，以下是转自exadel的一篇文。
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
- Components
- Render Kits
- Renderers
- Value Binding Expressions
- Event Model
- Extensibility
- Managed Beans (Dependency Injection)
- POJO Action Methods
- JSF is the standard Java-based web app framework
- 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都是杰出的MVC框架，JSF的设计者之一就是Struts的创始人。
Struts本人使用不多，只在一个project中用到，而且也仅仅是写了几个页面，那个project我主要做的是business layer部分。不过当时做struts时候感觉有时候真的很臃肿，每个有请求提交的页面都要对应一个actionform，每个actionform对应一个action类，觉得很麻烦。并且使用Struts所写的Action类和ActionForm类都依赖于Struts的API，不太符合编程优雅性的规则。而在JSF中，ActionForm和Action则被一个BackingBean所取代，该BackingBean是一个POJO(Plain Old Java Object)，页面请求的处理及导航则通过BackingBean中一个简单方法调用就可完成。
记得在某篇文里面提到JSF对ajax的支持性不太好，而据我所知java.net的blueprint早就提出了JSF层面上AJAX解决的三种方案。值得一提的是Apache Myfaces的的sandbox，有兴趣的可以去看看示例，链接http://www.irian.at/myfaces-sandbox/home.jsf ，给出了一些基于ajax的jsf组件。
当然，由于JSF目前还算是比较新的框架技术，组件还在不断扩展和完善中，不过既然它是JEE 5.0的实现标准，我看好它的潜力。Facelets也使得web页面的模板化更加容易。自从jsf出现以后，struts阵营的不少人转向了jsf，比如Professional Struts的作者之一Rick Hightower。
国内不少java程序员对jsf持有抵制态度，毕竟学习一个新的技术框架需要时间，struts已经用了好多年了，用的很熟，干吗要放弃这个？我想说的是程序员就是生活在不断的学习中，为什么国外的软件人能写程序写几十年，而国内30岁之后的软件人还在写程序的少之又少。
