JSF 和 STRUTS 区别

JSF与Struts的区别

Struts和JSF/Tapestry都属于表现层框架，这两种分属不同性质的框架，后者是一种事件驱动型的组件模型，而Struts只是单纯的MVC 模式框架，老外总是急吼吼说事件驱动型就比MVC模式框架好，何以见得，我们下面进行详细分析比较一下到底是怎么回事？

　　首先事件是指从客户端页面（浏览器）由用户操作触发的事件，Struts使用Action来接受浏览器表单提交的事件，这里使用了Command模式，每个继承Action的子类都必须实现一个方法execute。

　　在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说：在Struts中实际是一 个表单只能对应一个事件，struts这种事件方式称为application event，application event和component event相比是一种粗粒度的事件。

　　struts重要的表单对象ActionForm是一种对象，它代表了一种应用，这个对象中至少包含几个字段，这些字段是Jsp页面表单中的 input字段，因为一个表单对应一个事件，所以，当我们需要将事件粒度细化到表单中这些字段时，也就是说，一个字段对应一个事件时，单纯使用 Struts就不太可能，当然通过结合JavaScript也是可以转弯实现的。

　　而这种情况使用JSF就可以方便实现，

<h:inputText id="userId" value="#{login.userId}">
　　<f:valueChangeListener type="logindemo.UserLoginChanged" />
</h:inputText>

　　#{login.userId}表示从名为login的JavaBean的getUserId获得的结果，这个功能使用struts也可以实现，name="login" property="userId"

　　关键是第二行，这里表示如果userId的值改变并且确定提交后，将触发调用类UserLoginChanged的processValueChanged(...)方法。

　　JSF可以为组件提供两种事件：Value Changed和 Action. 前者我们已经在上节见识过用处，后者就相当于struts中表单提交Action机制，它的JSF写法如下：

<h:commandButton id="login" commandName="login">
　　<f:actionListener type=”logindemo.LoginActionListener” />
</h:commandButton>

　　从代码可以看出，这两种事件是通过Listerner这样观察者模式贴在具体组件字段上的，而Struts此类事件是原始的一种表单提交 Submit触发机制。如果说前者比较语言化（编程语言习惯做法类似Swing编程）；后者是属于WEB化，因为它是来自Html表单，如果你起步是从 Perl/PHP开始，反而容易接受Struts这种风格。

基本配置

　　Struts和JSF都是一种框架，JSF必须需要两种包JSF核心包、JSTL包（标签库），此外，JSF还将使用到Apache项目的一些commons包，这些Apache包只要部署在你的服务器中既可。

　　JSF包下载地址：http://java.sun.com/j2ee/javaserverfaces/download.html 选择其中Reference Implementation。

　　JSTL包下载在http://jakarta.apache.org/site/downloads/downloads_taglibs-standard.cgi

　　所以，从JSF的驱动包组成看，其开源基因也占据很大的比重，JSF是一个SUN伙伴们工业标准和开源之间的一个混血儿。

　　上述两个地址下载的jar合并在一起就是JSF所需要的全部驱动包了。与Struts的驱动包一样，这些驱动包必须位于Web项目的WEB-INF/lib，和Struts一样的是也必须在web.xml中有如下配置：

<web-app>
　　<servlet>
　　　　<servlet-name>Faces Servlet</servlet-name>
　　　　<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
　　　　<load-on-startup>1</load-on-startup>
　　</servlet>

　　<servlet-mapping>
　　　　<servlet-name>Faces Servlet</servlet-name>
　　　　<url-pattern>*.faces</url-pattern>
　　</servlet-mapping>
</web-app>

　　这里和Struts的web.xml配置何其相似，简直一模一样。

　　正如Struts的struts-config.xml一样，JSF也有类似的faces-config.xml配置文件：

<faces-config>
　　<navigation-rule>
　　　　<from-view-id>/index.jsp</from-view-id>
　　　　<navigation-case>
　　　　　　<from-outcome>login</from-outcome>
　　　　　　<to-view-id>/welcome.jsp</to-view-id>
　　　　</navigation-case>
　　</navigation-rule>

　　<managed-bean>
　　　　<managed-bean-name>user</managed-bean-name>
　　　　<managed-bean-class>com.corejsf.UserBean</managed-bean-class>
　　　　<managed-bean-scope>session</managed-bean-scope>
　　</managed-bean>
</faces-config>

 

　　在Struts-config.xml中有ActionForm Action以及Jsp之间的流程关系，在faces-config.xml中，也有这样的流程，我们具体解释一下Navigation：

　　在index.jsp中有一个事件：

<h:commandButton label="Login" action="login" />

　　action的值必须匹配form-outcome值，上述Navigation配置表示：如果在index.jsp中有一个login事件，那么事件触发后下一个页面将是welcome.jsp

　　JSF有一个独立的事件发生和页面导航的流程安排，这个思路比struts要非常清晰。

　　managed-bean类似Struts的ActionForm，正如可以在struts-config.xml中定义ActionForm的scope一样，这里也定义了managed-bean的scope为session。

　　但是如果你只以为JSF的managed-bean就这点功能就错了，JSF融入了新的Ioc模式/依赖性注射等技术。

Ioc模式

　　对于Userbean这样一个managed-bean，其代码如下：

public class UserBean {
　　private String name;
　　private String password;

　　// PROPERTY: name
　　public String getName() { return name; }
　　public void setName(String newValue) { name = newValue; }

　　// PROPERTY: password
　　public String getPassword() { return password; }
　　public void setPassword(String newValue) { password = newValue; }
}

<managed-bean>
　　<managed-bean-name>user</managed-bean-name>
　　<managed-bean-class>com.corejsf.UserBean</managed-bean-class>
　　<managed-bean-scope>session</managed-bean-scope>

　　<managed-property>
　　　　<property-name>name</property-name>
　　　　<value>me</value>
　　</managed-property>

　　<managed-property>
　　　　<property-name>password</property-name>
　　　　<value>secret</value>
　　</managed-property>
</managed-bean>

　　faces-config.xml这段配置其实是将"me"赋值给name，将secret赋值给password，这是采取Ioc模式中的Setter注射方式 。

Backing Beans

　　对于一个web form，我们可以使用一个bean包含其涉及的所有组件，这个bean就称为Backing Bean， Backing Bean的优点是：一个单个类可以封装相关一系列功能的数据和逻辑。

　　说白了，就是一个Javabean里包含其他Javabean，互相调用，属于Facade模式或Adapter模式。

　　对于一个Backing Beans来说，其中包含了几个managed-bean，managed-bean一定是有scope的，那么这其中的几个managed-beans如何配置它们的scope呢？

<managed-bean>
　　...
　　<managed-property>
　　　　<property-name>visit</property-name>
　　　　<value>#{sessionScope.visit}</value>
　　</managed-property>

　　这里配置了一个Backing Beans中有一个setVisit方法，将这个visit赋值为session中的visit，这样以后在程序中我们只管访问visit对象，从中获取 我们希望的数据（如用户登陆注册信息），而visit是保存在session还是application或request只需要配置既可。

UI界面

　　JSF和Struts一样，除了JavaBeans类之外，还有页面表现元素，都是是使用标签完成的，Struts也提供了struts-faces.tld标签库向JSF过渡。

　　使用Struts标签库编程复杂页面时，一个最大问题是会大量使用logic标签，这个logic如同if语句，一旦写起来，搞的JSP页面象俄罗斯方块一样，但是使用JSF标签就简洁优美：

<jia:navigatorItem name="inbox" label="InBox"
　　icon="/images/inbox.gif"
　　action="inbox"
　　disabled="#{!authenticationBean.inboxAuthorized}"/>

　　如果authenticationBean中inboxAuthorized返回是假，那么这一行标签就不用显示，多干净利索！

　　先写到这里，我会继续对JSF深入比较下去，如果研究过Jdon框架的人，可能会发现，Jdon框架的jdonframework.xml中 service配置和managed-bean一样都使用了依赖注射，看来对Javabean的依赖注射已经迅速地成为一种新技术象征，如果你还不了解 Ioc模式，赶紧补课。
附Jsf核心教程一个JSF案例:login.rar

posted on 2005-09-23 22:17 风 阅读(1784) 评论(4)  编辑  收藏 所属分类: JSF

View Comments

#   re: JSF与Struts的区别   回复   更多评论   

JSF的事件驱动是否会绕过http的响应，简单的说当触发到JSF的事件时，能不能在页面不刷新的条件下完成。

2005-09-24 09:15 | fanta

#   re: JSF与Struts的区别   回复   更多评论   

JSF毕竟是基于JSP的，所以Page的编写应该是比较烦琐的。
<jia:navigatorItem name="inbox" label="InBox"
　　icon="/images/inbox.gif"
　　action="inbox"
　　disabled="#{!authenticationBean.inboxAuthorized}"/>
是一种进化，不必象用JSTL或者struts的Logic标签那样麻烦，其实Tapestry做得的更彻底，他根本上抛弃了JSP的tag。全 部采用和例子中风格一致的方式实现。真正做到模板和Java代码完全独立。对于我这种不喜欢前台工作的程序员来说，真是一种福音，只可惜Tapestry 目前还不够成熟。

2005-09-24 09:32 | InPractice

#   re: JSF与Struts的区别   回复   更多评论   

我试验的用过tapestry，感觉这个东西还可以，因为它的原理是用html中加入标志性标签，标识那一部分应为tapestry来解析，然后由tapestry动态的ONGL翻译，然后转换到组件，最后使用servlet解析，变量print输出。
但我认为不要的地方在于：
1。页面调试不方便。每一次html的改变都要做起servlet服务器。
2。文档少，例子少。

我现在正要用jsf开发，感觉这人东西，在jsp基础上还可以，上手要比tapestry快，而且文档比较多。而它还使用的简单的ioc和Decorator模式，组件可维护。主流的IDE基本都支持jsf了，感觉要比tapestry好一些。

我这边有个项目组和typestry3.0开发项目，感觉框架是分出来了，开发效果并不是非常好..

他是tomcat+oracle+typestry3+hibernate架构...
结果每次有字段调整，除了hibernate的map文件可以自动生成外，其余要全部检查过。虽然偶用了3小时写了一个从pdm文件到typestry的三个文件的自动生成工具，但是他们还是不堪重负，感觉出不了活。

而且每次修改都要修改三个部分java,jwc,html。

再一个，他在设计思想上有些排斥其它技术，因此，想入主流相对来说比较困难，建议：学习一下思路可以用它，如果是开发，要慎重考虑。

我一直没有解决的一个问题，在用了typestry后，解决了，就是偶借用了他的html模板概念，使我的框架有了一个质的飞跃.

以上只是我的个人观点。