模板
教程
环境
性能
功能
管理
JSP/Servlet:JSF相对于Struts的一些优点
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
