使用 JSF 架构进行设计 探索 JavaServer Faces 框架中使用的设计模式

未显示需要 JavaScript 的文档选项 拓展 Tomcat 应用 下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1

级别: 中级

Anand Prakash Joshi (ananjosh@in.ibm.com), 软件工程师, IBM

2006 年 1 月 04 日

本文中，作者 Anand Joshi 使用 JSF 框架中的设计模式阐释了 JavaServer Faces (JSF) 体系结构。他讨论了 JSF 体系结构中使用的 GoF 设计模式，以及这些模式在 JSF 框架中的作用。任何对设计模式和 JSF 体系结构有一定了解的人都能从 Anand 详细的介绍中有所收获。*读者应该对 GoF 设计模式和 JSF 技术有很好的了解。

设计模式可以帮助用户在更高层次上抽象细节，更好地理解体系结构。如果比较熟悉 GoF 设计模式和 JavaServer Faces (JSF) 框架，本文可以帮助您洞察 JSF 框架中使用的设计模式，深入理解其工作原理。

本文探讨了 JSF 框架中使用的设计模式。详细讨论的设计模式包括 Singleton、Model-View-Controller、Factory Method、State、Composite、Decorator、Strategy、Template Method 和 Observer 模式。

设计模式和 JavaServer Faces (JSF) 技术

首先简要地介绍一下模式和 JSF 框架。

• 模式。设计模式是对问题和解决方案进行抽象的普遍适用的方法。因为模式是所有开发人员和架构师公认的，所以模式可以节约时间和资源。用外行话来说，模式就是关于某个人所共知的问题的经过验证的解决方案。模式可以重用，重用使得解决方案更健壮。
• Java Server Faces。 JSF 体系结构是一种 Web 应用程序框架。它是 Java Community Process (JCP) 推动的，有望成为 Web 应用程序开发的标准框架。目前用于开发 Web 应用程序的框架有 50 多个，这说明迫切需要实现框架的标准化，这正是 JSF 框架的目标！

深入剖析 JSF 模式

现在我们来讨论 JSF 体系结构中的各种设计模式。本文将详细讨论 Singleton、Model-View-Controller、Factory Method、State、Composite、Decorator、Strategy、Template Method 和 Observer 设计模式。我将分析每种模式的用途及其在 JSF 框架中的作用。

Singleton 模式

Singleton 模式的目的是保证类只有一个实例被加载，该实例提供一个全局访问点。当启动具有 JSF 支持的 Web 应用程序时，Web 容器初始化一个 FacesServlet 实例。在这个阶段，FacesServlet 对每个 Web 应用程序实例化 Application 和 LifeCycle 实例一次。这些实例就采用众所周知的 Singleton 模式，通常只需要该类型的一个实例。

使用 JSF 的 Web 应用程序只需要 Application 和 LifeCycle 类的一个实例。LifeCycle 管理多个 JSF 请求的整个生命期。因为其状态和行为在所有请求之间共享，这些对象采用 Singleton 模式合情合理。LifeCycle 维护的 PhaseListeners 也是 Singleton 模式的。PhaseListeners 由所有 JSF 请求共享。在 JSF 框架中可以广泛使用 Singleton 模式，以减少内存占用和提供对象的全局访问。NavigationHandler（用于确定请求的逻辑结果）和 ViewHandler（用于创建视图）也是使用 Singleton 模式的例子。

Model-View-Controller (MVC)

MVC 模式的目的是从数据表示（View）中将数据（即 Model）分离出来。如果应用程序有多种表示，可以仅替换视图层而重用控制器和模型代码。类似的，如果需要改变模型，可以在很大程度上不改变视图层。控制器处理用户动作，用户动作可能造成模型改变和视图更新。当用户请求一个 JSF 页面时，请求发送到 FacesServlet。FacesServlet 是 JSF 使用的前端控制器 servlet。和其他很多 Web 应用程序框架一样，JSF 使用 MVS 模式消除视图和模型之间的耦合。为了集中处理用户请求，控制器 servlet 改变模型并将用户导航到视图。

FacesServlet 是 JSF 框架中所有用户请求都要经过的控制器元素。FacesServlet 分析用户请求，使用托管 bean 对模型调用各种动作。后台（backing）或托管（managed）bean 就是该模型的例子。JSF 用户界面（UI）组件是视图层的例子。MVC 模式把任务分解给具有不同技能的开发人员，使这些任务能够同时进行，这样 GUI 设计人员就可以使用丰富的 UI 组件创建 JSF 页面，同时后端开发人员可以创建托管 bean 来编写专门的业务逻辑代码。

Factory Method 模式

Factory Method 模式的目的是定义一个用于创建对象的接口，但是把对象实例化推迟到子类中。在 JSF 体系结构中，Factory Method 模式被用于创建对象。LifeCycleFactory 是一个创建和返回 LifeCycle 实例的工厂对象。LifeCycleFactory 的 getLifeCycle (String LifeCycleId) 方法采用 Factory Method 模式，根据 LifeCycleId 创建（如果需要）并返回 LifeCycle 实例。自定义的 JSF 实现可以重新定义 getLifeCycle 抽象方法来创建自定义的 LifeCycle 实例。默认的 JSF 实现提供默认的 LifeCycle 实例。此外，对于每个 JSF 请求，FacesServlet 都从 FacesContextFactory 得到 FacesContext。FacesContextFactory 是一个抽象类，公开了 getFacesContext API，JSF 实现提供了 FacesContextFactory 和 getFacesContext API 的具体实现。这是另外一个使用 Factory Method 模式的例子，具体的 FacesContextFactory 实现创建 FacesContext 对象。

State 模式

State 模式的目的是在表示状态的不同类之间分配与状态有关的逻辑。FacesServlet 对 LifCycle 实例调用 execute 和 render 方法。LifeCycle 协调不同的 Phrase 以便执行 JSF 请求。在这里 JSF 实现就遵循了 State 模式。如果没有使用这种模式，LifeCycle 实现就会被大量的条件（即 “if” 语句）搅得一塌糊涂。JSF 实现为每个状态（或阶段）创建单独的类并调用 step。phase 是一个抽象类，定了每个 step 的公共接口。在 JSF 框架中定义了六个 phrase（即 step）：RestoreViewPhase、ApplyRequestValues、ProcessValidationsPhase、UpdateModelValuesPhase、InvokeApplicationPhase 和 RenderResponsePhase。

在 State 模式中，LifeCycle 把 FacesContext 对象传递给 phase。每个阶段或状态改变传递给它的上下文信息，然后设置 FacesContext 本身中的标志表明下一个可能的步骤。JSF 实现在每个步骤中改变其行为。每个阶段都可以作为下一个阶段的起因。FacesContext 有两种标志 renderResponse 和 responseComplete 可以改变执行的顺序。每个步骤执行完成后，LifeCycle 检查上一阶段是否设置了这些标志。如果设置了 responseComplete，LifeCycle 则完全放弃请求的执行。如果经过某个阶段后设置了 renderResponse 标志，JSF 就会跳过剩下的阶段而直接进入 Render Response 阶段。如果这两个标志都没有设置，LifeCycle 就会按顺序继续执行下一步。

Composite 模式

Composite 模式让客户代码能够统一处理复合对象和基本对象。复合对象是基本对象的容器。在第一阶段（Restore View 阶段）和最后一个阶段（Render Response 阶段），使用 JSF UI 组件构造 UI View。UIComponentBase 就是 Composite 模式中 Component 抽象类的一个例子。UIViewRoot 是 Composite 类，而 UIOutput（比方说）就是叶子（或者基本类）。UIComponentBase 类定义了叶子和复合对象的公共方法，如编码/解码值和子节点管理函数。子节点管理函数，如 getChildren，对于叶子节点返回空列表，对于复合节点则返回其子节点。

Decorator 模式

Decorator 模式的目的是不通过子类化动态扩展对象的行为。JSF 框架有很多扩展点（即可插入机制）。JSF 实现可使用 Decorator 模式替换默认的 PropertyResolver、VariableResolver、ActionListener、NavigationHandler、ViewHandler 或 StateManager。通常自定义实现接受通过构造函数传递给它的默认实现的引用。自定义实现仅仅改写功能的一个子集，而将其他功能委托给默认实现。如果希望实现自定义的 ViewHandler，改写默认 ViewHandler 实现的 calculateLocale 方法，可以像 清单 1 那样编写 CustomViewHandler 类：

清单 1. CustomViewHandler 片段

public class CustomViewHandler extends ViewHandler {
 public CustomViewHandler(ViewHandler handler) {
		 super();
		 oldViewHandler = handler;
 }
private ViewHandler oldViewHandler  = null;
public void renderView (facesContext context, UIViewRoot view) {
            //delegate method to oldViewHandler
		 oldViewHandler.renderView(context, view);
}
//custom implementation of calculateLocale
public Locale calculateLocale(FacesContext context) {
}
}

Strategy 模式

Strategy 模式的目的是封装不同的概念。JSF 框架采用 Strategy 模式使用委托实现模型呈现 UI 组件。JSF 技术支持两种呈现模型。在直接实现模型中，UI 组件对收到的请求中的数据进行解码，然后编码这些数据进行显示。在委托实现模型中，解码和编码操作委托给和组建关联的专门呈现器。后一种模型利用了 Strategy 设计模式，比直接实现更灵活。在 Strategy 模式中，将不同的算法封装在单独的对象中，从而可以动态地改变算法。JSF 实现可以用已有的 renderkit 实例注册另外的呈现器，当应用程序启动的时候，JSF 实现读取配置文件将这些呈现器和 UI 组件联系在一起。

Template Method 模式

Template Method 模式的目的是将变化的步骤推迟到子类中，而在父类中定义那些固定的算法步骤。JSF 框架通过 PhraseListeners 展现了 Template Method 模式提供的功能。采用 Template Method（或者 “hook”）使得 Web 作者可以为不同阶段之间的可选步骤提供实现，而主要阶段仍然和 JSF 框架的定义一致。JSF 框架提供了 PhaseListeners，概念上类似于 Template Method 模式中的可变步骤。JSF 框架有六个预定义的阶段，在每个阶段之间，Web 作者可以实现 PhaseListeners 来提供类似于 Template Method hook 的 hook。事实上，这种结构比 Template Method 模式更具有扩展性。可以通过注册 PhraseId 为 ANY_PHRASE 的 PhaseListener 在每个阶段后提供 hook。如果 PhaseId 是 ANY_PHASE，JSF 实现就会在每个阶段之前和之后调用该 PhaseListener。JSF 框架中的实现略有不同，因为可以根本没有 PhaseListener，但是在 Template Method 模式中，子类通常重新定义父类中抽象的可变步骤。

Observer 模式

Observer 模式的目的是当目标对象的状态改变时自动通知所有依赖的对象（即观察器）。JSF 在 UI 组件中实现了 Observer 模式。JSF 有两类内建事件：ActionEvent 和 ValueChangedEvent。ActionEvent 用于确定用户界面组件（如按钮）的激活。当用户单击按钮时，JSF 实现通知添加到该按钮上的一个或多个动作监听程序。于是该按钮被激活，或者说按钮（主体）的状态改变了。添加到按钮上的所有监听程序（即观察器）都收到通知该主体状态已经改变。类似的，当输入 UI 组件中的值改变时，JSF 实现通知 ValueChangeListener。

结束语

JSF 框架利用了 Singleton、Model-View-Controller、Factory Method、State、Composite、Decorator、Strategy、Template Method 和 Observer 设计模式。因为它的体系结构建立在已经验证的设计模式的基础上，这是一个健壮的框架，模式在 JSF 框架中得到了很好的利用。

参考资料

• 请访问 Gang of Four Design Patterns 进一步了解这些设计模式。
  
  
• 请阅读 “怀疑论者的 JSF: JSF 应用程序的生命周期” 进一步了解 JavaServer Faces 框架（developerWorks，2005 年 3 月）。
  
  
• 请访问 developerWorks Java 技术专区。这里专门发表各种基于 Web 和 Java 的解决方案的文章和教程。
  
  

• 从 Sun Developer Network 免费 下载 JSF。
  
  
• 下载 IBM Rational Software Architect 的免费试用版。
  
  

• 参与 developerWorks blogs 并加入 developerWorks 社区。
  
  
• 参与 Sun Developer Network 上的 Java 论坛 —— JavaServer Faces Technology。

关于作者

		Anand 是一位 Sun 认证的企业架构师，几年来一直研究 Web 技术。他对 WebSphere 管理控制台应用程序的设计和开发做了多方面的贡献。Anand 曾经在 IBM 美国工作过几年，目前在 IBM 印度工作。

• 每个产品必须具有唯一的ID
• 每个产品必须属于至少一个category
  
• 产品ID一旦创立不得修改

• 英语讲是缺省语言，且不需事先国际化
• 在Catalog不讲不会超过500个产品
• catalog将不会被频繁的修改

• JDBC：这是最为灵活的方法，然而，低级的JDBC难以使用，而且质量差的JDBC代码很难运转良好
• Entity beans：CMP的Entity bean是一种分离数据访问代码和处理ORM的昂贵的方法，它是以应用服务器为中心的方法，即entity bean不是将应用与某种数据库类型而是EJB容器约束在一起。
• O/R mapping framework：一个ORM框架采用以对象为中心的方法实现数据持续化，一个以对象为中心的应用易于开发并具有高度的可移植性。在该领域中存在几个框架可用—JDO、Hibernate、TopLink以及CocoBase等。在我们的范例中将选用Hibernate。

• 类Swing的面向对象的Web应用开发：服务器端有状态的UI组件模型，配合event listeners和handlers，促进了面向对象的Web应用开发。
• backing-bean管理： backing bean是与页面中使用的UI组件相关联的javabean组件，backing-bean管理将UI组件对象的定义同执行应用相关处理和拥有数据的对象分离开来。JSF在合适的范围内保存和管理这些backing-bean实例。
• 可扩展的UI模型：JSF的UI模型是可配置的、可重用的，用以构建JSF应用的用户界面。你可以通过扩展标准的UI组件来开发出更为复杂的组件，例如菜单条、树组件等。
• 灵活的rendering模型：renderer分离了UI组件的功能和显示，多个renderers可创建和用来为同一客户端或不同的客户端定义不同的显示。
• 可扩展的转换和验证模型：基于标准的converter和validator，你可以开发出自己的可提供更好的模型保护的converter和validator。

• 利用一个backing bean：这一个方法非常简单，然而它却将backing bean与特殊的继承关系结合起来了
• 利用JSF的ViewHandler decorator：这一方法中，安全逻辑紧密地与一特定Web层技术联系在了一起
• 利用servlet filter：一个JSF应用与其他的Web应用没有什么两样，filter仍是处理认证检查的最好地方，这种方法中，认证逻辑与Web应用分离开来

• Bean management with application contexts：Spring可以有效地组织我们的中间层对象，它能够消除singleton的proliferation，并易于实现良好的面向对象编程方法，即“编程到接口”。
• Declarative Transaction management: Spring利用AOP实现事务管理，而无需借助于EJB容器，利用这种方法，事务管理可以用于任何POJO中。Spring的事务管理不局限于JTA，而是可以采用不同的事务策略，在范例应用中，我们将使用declarative transaction management with Hibernate transaction。
• Data-access exception hierarchy：Spring提供了非常好的异常来代替SQLException，为利用Spring的异常，必须在Spring的配置文件中定义以下异常转换：

• Hibernate integration：Spring与Hibernate这样的ORM框架整合的非常好，Spring提供了对Hibernate session的高效和安全的处理，它可通过application context配置Hibernate的SessionFactories和JDBC数据源，并使得应用易于测试。

• JSP page：createProduct.jsp是用来创建新产品的页面，它包含UI组件并将组件打包成ProductBean，ValidateItemsRange标签用来验证用户选择的种类数量，对每一个产品至少要有一个种类被选中。

• 页面导航：应用中的导航被定义在应用的配置文件faces-navigation.xml中，CreateProduct的导航准则如下：

   *
  
      createProduct
      /createProduct.jsp
  

   /createProduct.jsp
  
      success
      /uploadImage.jsp
  
  
      retry
      /createProduct.jsp
  
  
      cancel
      /productList.jsp
  

• Backing bean：ProductBean不仅包含有将数据映射到页面上的UI组件的属性，还包括三个action：createAction、editAction和deleteAction，下面是createAction方法的代码：

public String createAction() {
   try {
      Product product = ProductBeanBuilder.createProduct(this);

      //Save the product.
      this.serviceLocator.getCatalogService().saveProduct(product);

      //Store the current product id inside the session bean.
      //For the use of image uploader.
      FacesUtils.getSessionBean().setCurrentProductId(this.id);

      //Remove the productList inside the cache.
      this.logger.debug("remove ProductListBean from cache");
      FacesUtils.resetManagedBean(BeanNames.PRODUCT_LIST_BEAN);
   } catch (DuplicateProductIdException de) {
      String msg = "Product id already exists";
      this.logger.info(msg);
      FacesUtils.addErrorMessage(msg);

      return NavigationResults.RETRY;
   } catch (Exception e) {
      String msg = "Could not save product";
      this.logger.error(msg, e);
      FacesUtils.addErrorMessage(msg + ": Internal Error");

      return NavigationResults.FAILURE;
   }
   String msg = "Product with id of " + this.id + " was created successfully.";
   this.logger.debug(msg);
   FacesUtils.addInfoMessage(msg);

   return NavigationResults.SUCCESS;
}

• Managed-bean声明：ProductBean必须在JSF配置文件faces-managed-bean.xml中配置：

  
      Backing bean that contains product information.
  
   productBean
   catalog.view.bean.ProductBean
   request   
  
      id
      #{param.productId}
  
  
      serviceLocator
      #{serviceLocatorBean}
  

•  表示层和业务逻辑层之间的整合： ServiceLocator抽象了查找服务的逻辑，在范例应用中，ServiceLocator被定义为一个接口，该接口实现为一个JSF的 managed bean，即ServiceLocatorBean，它将在Spring的application context中寻找服务：

ServletContext context = FacesUtils.getServletContext();
this.appContext = WebApplicationContextUtils.getRequiredWebApplicationContext(context);
this.catalogService = (CatalogService)this.lookupService(CATALOG_SERVICE_BEAN_NAME);
this.userService = (UserService)this.lookupService(USER_SERVICE_BEAN_NAME);

• 业务对象：由于采用Hibernate提供持久化，因此Product和Category两个业务对象需要为它们的所有field提供getter和setter。

• 业务服务：CatalogService接口中定义了所有的与Catalog management相关的服务：

public interface CatalogService {
   public Product saveProduct(Product product) throws CatalogException;
   public void updateProduct(Product product) throws CatalogException;
   public void deleteProduct(Product product) throws CatalogException;
   public Product getProduct(String productId) throws CatalogException;
   public Category getCategory(String categoryId) throws CatalogException;
   public List getAllProducts() throws CatalogException;
   public List getAllCategories() throws CatalogException;
}

• Spring Configuration：这里是CatalogService的Spring配置：

  




  




  
  
  
     
         PROPAGATION_REQUIRED,readOnly
       PROPAGATION_REQUIRED
       PROPAGATION_REQUIRED
       PROPAGATION_REQUIRED
     
  

• Spring和Hibernate的整合：下面是HibernateSessionFactory的配置：

<!-- Hibernate SessionFactory Definition -->
<bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
   <property name="mappingResources">
      <list>
         <value>catalog/model/businessobject/Product.hbm.xml</value>
         <value>catalog/model/businessobject/Category.hbm.xml</value>
         <value>catalog/model/businessobject/User.hbm.xml</value>
      </list>
   </property>
   <property name="hibernateProperties">
      <props>
         <prop key="hibernate.dialect">net.sf.hibernate.dialect.MySQLDialect</prop>
       <prop key="hibernate.show_sql">true</prop>
       <prop key="hibernate.cglib.use_reflection_optimizer">true</prop>
       <prop key="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</prop>
      </props>
   </property>
   <property name="dataSource">
      <ref bean="dataSource"/>
   </property>
</bean>

CatalogDao uses HibernateTemplate to integrate between Hibernate and Spring. Here's the configuration for HibernateTemplate:

<!-- Hibernate Template Defintion -->
<bean id="hibernateTemplate" class="org.springframework.orm.hibernate.HibernateTemplate">
   <property name="sessionFactory"><ref bean="sessionFactory"/></property>
   <property name="jdbcExceptionTranslator"><ref bean="jdbcExceptionTranslator"/></property>
</bean>


<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
      "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
      "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">
<hibernate-mapping package="catalog.model.businessobject">
   <class name="Product" table="product">
      <id name="id" column="ID" unsaved-value="null">
         <generator class="assigned"/>
      </id>
      <property name="name" column="NAME" unique="true" not-null="true"/>
      <property name="price" column="PRICE"/>    
      <property name="width" column="WIDTH"/>      
      <property name="height" column="height"/>      
      <property name="description" column="description"/>   
      <set name="categoryIds" table="product_category" cascade="all">
         <key column="PRODUCT_ID"/>
         <element column="CATEGORY_ID" type="string"/>
      </set>
   </class>
</hibernate-mapping>

CatalogDao is wired with HibernateTemplate by Spring:

<!-- Catalog DAO Definition: Hibernate implementation -->
<bean id="catalogDao" class="catalog.model.dao.hibernate.CatalogDaoHibernateImpl">
   <property name="hibernateTemplate"><ref bean="hibernateTemplate"/></property>
</bean>


板桥里人 http://www.jdon.com 2005/09/05

　　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就可以方便实现，

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

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

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

　　从代码可以看出，这两种事件是通过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中有如下配置：

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

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

　　在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; }
}

　　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呢？

　　这里配置了一个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标签就简洁优美：

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

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

附Jsf核心教程一个JSF案例:login.rar

相关讨论：

表现层框架Struts/Tapestry/JSF架构比较

讨论