}
  return itr;
 } 
    
      好了一旦我们做好了上边的工作，查询对我们来说将是很容易的一件事情，而且可以达到公用，是不是省了许多力气？下面我将实例化一个例子来进一步说明：
     
      例子：
      HQuery hquery=HQuery();
      hquery.setQueryString("select users from Users as users where users.name=? and users.sex=?");
      hquery.setOrderby("order by users.age desc");
     
      //如果要分页，把当前页curpage传递给hquery
      hquery.setPageStartNo(curpage);
     
      //实例化参数，本例为两个参数
      Paras paras1=new Paras();
      paras1.setPName(name);
      paras1.setTypeNo(Types.VARCHAR);
     
      Paras paras2=new Paras();
      paras2.setPName(sex);
      paras2.setTypeNo(Types.INTEGER);
     
      ParasList paraslist=new ParasList();
      paraslist.add(paras1);
      paraslist.add(paras2);//注意顺序
     
      hquery.setParalist(paraslist);
     
      //好了，做好准备工作，调用查寻方法得到结果
      List list=find(hquery);
     
      完成，有兴趣的网又可以据此跳到find中看看具体执行情况，如果这样相信你会有更进一步得了解。还是那句话，这个解决方案也有不足的地方，如果你有更好的意见或方法，请和我联系。
     
      Jplateau

　　设计模式可以帮助用户在更高层次上抽象细节，更好地理解体系结构。如果比较熟悉 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 框架中得到了很好的利用。

参考资料

学习

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

获得产品和技术

通过面向特征的编程减少编码时间和重复。

目前编程中最热门的新概念是面向特征的编程（ASpECt-oriented Programming，AOP）。AOP曾经主要用于学术和研发机构，如今开始进入主流开发领域。与OOP在面向过程的编程方法基础上的改进一样，AOP是在面向对象编程（OOP）方法的基础上进行改进而来的一种创新的软件开发方法。OOP引入了封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。然而，OOP在处理范围扩展到一些无关对象的公共行为方面达不到要求。也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如，看一下日志功能。日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。对于其他类型的代码，如安全性、异常处理和透明的持续性也是如此。这种散布在各处的无关的代码被称为横切（CROSs-cutting）代码，这也是AOP编码方法产生的原因。

AOP提供一种提取横切代码的方法，这种横切代码横跨各个对象层次，但与它所跨越的对象代码在功能上没有相关性。AOP不是在类中嵌入横切代码，而是允许你将横切代码提取到一个单独的模块中，然后在需要的时候动态地应用该代码，这个单独的模块叫做一个"特征代码"（"aspect"，也译作"标记"）。通过在你的对象模型中需要应用横切代码的地方定义特定的位置--切入点（pointcut）--来实现动态的应用横切代码。在运行或编译时，根据你的AOP框架，横切代码被插入指定的切入点。本质上说，AOP允许你在对象中引入新功能，而对象无需了解所引入的功能。这是一个非常有用的概念。

       事实上,Spring中的事务处理是通过AOP思想来实现的,Spring AOP与Aspect J和JBoss具有很大的不同,首先,使用Spring AOP框架的用户要记住的一点是,Spring AOP针对的是方法层次上的实现,而其他两者对字段也提供了支持.说到Spring AOP的内幕,其实也不难,对于有接口的类,使用的是Java内部类提供的Proxy;而对于那些不实现接口的类,使用的是cglib库,动态创建一个子类来实现.

      在Spring AOP中提供了4种处理切入类型:around,before,after,introduction.顾名思义,

     1)around是针对具体的某个切入点的方法(比如,现在有个OrderBook方法,around的切入类型是就这个方法的内部调用,是通过java的元数据,在运行时通过Method.invoke来调用,具有返回值,当发生意外的时候会终止.记住的一点是,返回值.);

    2)before是在方法调用前调用(在OrderBook方法前调用,但是没有返回值,同时在通常意外情况下,会继续运行下一步方法.记住的一点是没有返回值);

    3)after和before刚好相反,没有什么特别的地方.

    4)introduction是一个更加特殊的,但功能更加强大的切入类型.比如(你现在有Book对象,Computer对象,还有几十个这种业务对象,现在你希望在每个这样的对象中都加入一个记录最后修改的时间.但是你又不希望对每个类都进行修改,因为太麻烦了,同时更重要的一点,破坏了对象的完整性,说不定你以后又不需要这个时间数据了呢...这时怎么办呢?Spring AOP就为你专门实现这种思想提供了一个切入处理,那就是introduction.introduction可以为你动态加入某些方法,这样可以在运行时,强制转换这些对象,进行插入时间数据的动作,更深的内幕就是C++虚函数中的vtable思想).不过这种动态是以性能作为代价的,使用之前要慎重考虑,这里我们谈的是技术,所以就认为他是必需的.

     好,现在我们就拿第四种来进行举例说明Spring AOP的强大之处:

1)假设创建了一个BookService接口及其实现方法(你自己的业务对象):

//$ID:BookService.java Created:2005-11-6 by Kerluse Benn
package com.osiris.springaop;

public interface BookService {
 public String OrderComputerMagazine(String userName,String bookName);
 public String OrderBook(String userName,String bookName);
}

//$ID:BookServiceImpl.java Created:2005-11-6 by Kerluse Benn
package com.osiris.springaop;

public class BookServiceImpl implements BookService{
 public String OrderBook(String name,String bookName) {
  // TODO Add your codes here
  String result=null;
  result="订购"+bookName+"成功";
  return result;
 }

 public String OrderComputerMagazine(String userName, String bookName) {
  // TODO Add your codes here
  String result=null;
  result="订购"+bookName+"成功";
  return result;
 }
}

2)事实上你还有很多这样的对象,现在我们希望在每个对象中添加我们的功能最后修改的时间,功能如下:

//$ID:IAuditable.java Created:2005-11-7 by Kerluse Benn
package com.osiris.springaop.advices.intruduction;

import java.util.Date;

public interface IAuditable {
 void setLastModifiedDate(Date date);
 Date getLastModifiedDate();
}

3)因为我们使用的切入类型是introduction,Spring AOP为我们提供了一个描述这种类型的接口IntroductionInterceptor,所以我们的切入实现处理,也需要实现这个接口:

//$ID:AuditableMixin.java Created:2005-11-7 by Kerluse Benn
package com.osiris.springaop.advices.intruduction;

import java.util.Date;

import org.aopalliance.intercept.MethodInvocation;
import org.springframework.aop.IntroductionInterceptor;

public class AuditableMixin implements IAuditable,IntroductionInterceptor{
 private Date lastModifiedDate;
 
 public Object invoke(MethodInvocation m) throws Throwable {
  // TODO Add your codes here
  if(implementsInterface(m.getMethod().getDeclaringClass())){
   return m.getMethod().invoke(this,m.getArguments());
   //invoke introduced mthod,here is IAuditable
  }else{
   return m.proceed(); //delegate other method
  }
 }

 public Date getLastModifiedDate() {
  // TODO Add your codes here
  return lastModifiedDate;
 }

 public void setLastModifiedDate(Date date) {
  // TODO Add your codes here
  lastModifiedDate=date;
 }

 public boolean implementsInterface(Class cls) {
  // TODO Add your codes here
  return cls.isAssignableFrom(IAuditable.class);
 }
 
}
4)ok,现在业务对象BookService类有了,自己希望添加的处理也有了IAuditable,那就剩下使用Spring AOP框架的问题了,配置bean.xml文件:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
 <!-- Beans -->
 <bean id="BookServiceTarget" class="com.osiris.springaop.BookServiceImpl" singleton="false"/>

 <!-- introduction advice -->
 <bean id="AuditableMixin" class="com.osiris.springaop.advices.intruduction.AuditableMixin" singleton="false"/>

 <!-- Introduction advisor -->
 <bean id="AuditableAdvisor" class="org.springframework.aop.support.DefaultIntroductionAdvisor"
  singleton="false">
  <constructor-arg>
   <ref bean="AuditableMixin"/>
  </constructor-arg>
 </bean>
 
 <bean id="BookService" class="org.springframework.aop.framework.ProxyFactoryBean">
  <property name="target">
   <ref bean="BookServiceTarget"/>
  </property>
  
  <property name="singleton">
   <value>false</value>
  </property>
  
  <!-- force to use cglib -->
  <property name="proxyTargetClass">
   <value>true</value>
  </property>
  
  <!-- introduction methods -->
  <property name="proxyInterfaces">
   <value>com.osiris.springaop.advices.intruduction.IAuditable</value>
  </property>
  
  <property name="interceptorNames">
   <list>
    <value>AuditableAdvisor</value>
   </list>
  </property>
 </bean>
 
</beans>

以上就是配置文件,现在我们假设使用业务对象如下,这里是一个简单测试类:

//$ID:MainApp.java Created:2005-11-6 by Kerluse Benn
package com.osiris.springaop;

import java.util.Date;

import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.FileSystemResource;

import com.osiris.springaop.advices.intruduction.IAuditable;

public class MainApp {
 /**
  * @param args
  * @author Kerluse Benn
  */
 public static void main(String[] args) throws Exception{
  // TODO Add your codes here
  BeanFactory factory=new XmlBeanFactory(new FileSystemResource("bean.xml"));
  BookService bookService=(BookService)factory.getBean("BookService");
  IAuditable auditable=(IAuditable)bookService;
  System.out.print(bookService.OrderBook("Kerluse Benn","Professional C#"));
  auditable.setLastModifiedDate(new Date());
  System.out.println(" 订购时间为"+auditable.getLastModifiedDate());
  Thread.sleep(10000);
  System.out.print(bookService.OrderBook("Kerluse Benn","Expert j2ee one-on-one"));
  auditable.setLastModifiedDate(new Date());
  System.out.println(" 订购时间为"+auditable.getLastModifiedDate());
 }
}

输出结果:
订购Professional C#成功 订购时间为Mon Nov 07 11:35:20 CST 2005
订购Expert j2ee one-on-one成功 订购时间为Mon Nov 07 11:35:30 CST 2005

看见上面黑体字:

IAuditable auditable=(IAuditable)bookService;

由于bookService对象事实上已经实现了IAuditable接口,通过Spring AOP的introduction切入实现,所以在运行时(熟悉C++的vtable模型的可以在大脑里想一下)可以转换,我们就可以随意添加自己的接口方法了.

好了,关于Spring AOP就介绍到这了,其他相关的内容可以参考相应的书籍,这篇文章的目的主要是为了介绍一下AOP思想应用的强大之处.具体的相关应用还包括用户操作验证等等.

Web层实现

　　1、Web层的构件和交互流程

　　Web层包括主要3个功能：

　　·上传文件。

　　·列出所有已经上传的文件列表，以供点击下载。

　　·下载文件。

　　Web层实现构件包括与2个JSP页面，1个ActionForm及一个Action：

　　·file-upload.jsp：上传文件的页面。

　　·file-list.jsp：已经上传文件的列表页面。

　　·FileActionForm：file-upload.jsp页面表单对应的ActionForm。

　　·FileAction：继承org.apache.struts.actions.DispatchAction的Action，这样这个Action就可以通过一个URL参数区分中响应不同的请求。

　　Web层的这些构件的交互流程如图 6所示：

图 6 Web层Struts流程图

　　其中，在执行文件上传的请求时，FileAction在执行文件上传后，forward到loadAllFile出口中，loadAllFile加载数据库中所有已经上传的记录，然后forward到名为fileListPage的出口中，调用file-list.jsp页面显示已经上传的记录。

　　2、FileAction功能

　　Struts 1.0的Action有一个弱项：一个Action只能处理一种请求，Struts 1.1中引入了一个DispatchAction，允许通过URL参数指定调用Action中的某个方法，如http://yourwebsite/fileAction.do?method=upload即调用FileAction中的upload方法。通过这种方式，我们就可以将一些相关的请求集中到一个Action当中编写，而没有必要为某个请求操作编写一个Action类。但是参数名是要在struts-config.xml中配置的：

　　第6行的parameter="method"指定了承载方法名的参数，第9行中，我们还配置了一个调用FileAction不同方法的Action出口。

　　FileAction共有3个请求响应的方法，它们分别是：

　　·upload(…)：处理上传文件的请求。

　　·listAllFile(…)：处理加载数据库表中所有记录的请求。

　　·download（…）：处理下载文件的请求。

　　下面我们分别对这3个请求处理方法进行讲解。

　　2.1 上传文件

　　上传文件的请求处理方法非常简单，简之言之，就是从Spring容器中获取业务层处理类FileService，调用其save(FileActionForm form)方法上传文件，如下所示：

　　由于FileAction其它两个请求处理方法也需要从Spring容器中获取FileService实例，所以我们特别提供了一个getFileService()方法（第15~21行）。重构的一条原则就是："发现代码中有重复的表达式，将其提取为一个变量；发现类中有重复的代码段，将其提取为一个方法；发现不同类中有相同的方法，将其提取为一个类"。在真实的系统中，往往拥有多个Action和多个Service类，这时一个比较好的设置思路是，提供一个获取所有Service实现对象的工具类，这样就可以将Spring 的Service配置信息屏蔽在一个类中，否则Service的配置名字散落在程序各处，维护性是很差的。

　　2.2 列出所有已经上传的文件

　　listAllFile方法调用Servie层方法加载T_FILE表中所有记录，并将其保存在Request域中，然后forward到列表页面中：

　　file-list.jsp页面使用Struts标签展示出保存在Request域中的记录：

　　展现页面的每条记录挂接着一个链接地址，形如：fileAction.do?method=download&fileId=xxx，method参数指定了这个请求由FileAction的download方法来响应，fileId指定了记录的主键。

　　由于在FileActionForm中，我们定义了fileId的属性，所以在download响应方法中，我们将可以从FileActionForm中取得fileId的值。这里涉及到一个处理多个请求Action所对应的ActionForm的设计问题，由于原来的Action只能对应一个请求，那么原来的ActionForm非常简单，它仅需要将这个请求的参数项作为其属性就可以了，但现在一个Action对应多个请求，每个请求所对应的参数项是不一样的，此时的ActionForm的属性就必须是多请求参数项的并集了。所以，除了文件上传请求所对应的fileContent和remark属性外还包括文件下载的fileId属性：

图 7 FileActionForm

　　当然这样会造成属性的冗余，比如在文件上传的请求中，只会用到fileContent和remark属性，而在文件下载的请求时，只会使用到fileId属性。但这种冗余是会带来好处的--它使得一个Action可以处理多个请求。

　　2.3 下载文件

　　在列表页面中点击一个文件下载，其请求由FileAction的download方法来响应，download方法调用业务层的FileService方法，获取文件数据并写出到response的响应流中。通过合理设置HTTP响应头参数，将响应流在客户端表现为一个下载文件对话框，其代码如下所示：

　　代码 10 业务接口实现类之download

　　第15~18行，设置HTTP响应头，将响应类型设置为application/x-msdownload MIME类型，则响应流在IE中将弹出一个文件下载的对话框，如图 4所示。IE所支持的MIME类型多达26种，您可以通过这个网址查看其他的MIME类型：

http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp。

　　如果下载文件的文件名含有中文字符，如果不对其进行硬编码，如第18行所示，客户文件下载对话框中出现的文件名将会发生乱码。
第19行代码获得response的输出流，作为FileServie write(OutputStream os,String fileId)的入参，这样文件的内容将写到response的输出流中。

　　3、web.xml文件的配置

　　Spring容器在何时启动呢？我可以在Web容器初始化来执行启动Spring容器的操作，Spring提供了两种方式启动的方法：

　　·通过org.springframework.web.context .ContextLoaderListener容器监听器，在Web容器初始化时触发初始化Spring容器，在web.xml中通过＜listener＞＜/listener＞对其进行配置。

　　·通过Servlet org.springframework.web.context.ContextLoaderServlet，将其配置为自动启动的Servlet，在Web容器初始化时，通过这个Servlet启动Spring容器。

　　在初始化Spring容器之前，必须先初始化log4J的引擎，Spring也提供了容器监听器和自动启动Servlet两种方式对log4J引擎进行初始化：

　　·org.springframework.web.util .Log4jConfigListener

　　·org.springframework.web.util.Log4jConfigServlet

　　下面我们来说明如何配置web.xml启动Spring容器：

　　代码 11 web.xml中对应Spring的配置内容

　　启动Spring容器时，需要得到两个信息：Spring配置文件的地址和Log4J属性文件，这两上信息分别通过contextConfigLocationWeb和log4jConfigLocation容器参数指定，如果有多个Spring配置文件，则用逗号隔开，如：

/WEB-INF/applicationContext_1.xml, /WEB-INF/applicationContext_1.xm2

　　由于在启动ContextLoaderServlet之前，必须事先初始化Log4J的引擎，所以Log4jConfigServlet必须在ContextLoaderServlet之前启动，这通过＜load-on-startup＞来指定它们启动的先后顺序。

　　乱码是开发Web应用程序一个比较老套又常见问题，由于不同Web应用服务器的默认编码是不一样的，为了方便Web应用在不同的Web应用服务器上移植，最好的做法是Web程序自身来处理编码转换的工作。经典的作法是在web.xml中配置一个编码转换过滤器，Spring就提供了一个编码过滤器类CharacterEncodingFilter，下面，我们为应用配置上这个过滤器：

　　Spring的过滤器类是org.springframework.web.filter.CharacterEncodingFilter，通过encoding参数指定编码转换类型为GBK，＜filter-mapping＞的配置使该过滤器截获所有的请示。

　　Struts的框架也需要在web.xml中配置，想必读者朋友对Struts的配置都很熟悉，故在此不再提及，请参见本文所提供的源码。

　　总结

　　本文通过一个文件上传下载的Web应用，讲解了如何构建基于SSH的Web应用，通过Struts和FormFile，Spring的LobHandler以及Spring为HibernateBlob处理所提供的用户类BlobByteArrayType ，实现上传和下载文件的功能仅需要廖廖数行的代码即告完成。读者只需对程序作稍许的调整，即可处理Clob字段：

　　·领域对象对应Clob字段的属性声明为String类型；

　　·映射文件对应Clob字段的属性声明为org.springframework.orm.hibernate3.support.ClobStringType类型。

　　本文通过SSH对文件上传下载简捷完美的实现得以管中窥豹了解SSH强强联合构建Web应用的强大优势。在行文中，还穿插了一些分层的设计经验，配置技巧和Spring所提供的方便类，相信这些知识对您的开发都有所裨益。

Web层实现

　　1、Web层的构件和交互流程

　　Web层包括主要3个功能：

　　·上传文件。

　　·列出所有已经上传的文件列表，以供点击下载。

　　·下载文件。

　　Web层实现构件包括与2个JSP页面，1个ActionForm及一个Action：

　　·file-upload.jsp：上传文件的页面。

　　·file-list.jsp：已经上传文件的列表页面。

　　·FileActionForm：file-upload.jsp页面表单对应的ActionForm。

　　·FileAction：继承org.apache.struts.actions.DispatchAction的Action，这样这个Action就可以通过一个URL参数区分中响应不同的请求。

　　Web层的这些构件的交互流程如图 6所示：

图 6 Web层Struts流程图

图 7 FileActionForm

业务层

　　1、业务层接口

　　"面向接口而非面向类编程"是Spring不遗余力所推荐的编程原则，这条原则也已经为大部开发者所接受；此外，JDK的动态代理只对接口有效，否则必须使用CGLIB生成目标类的子类。我们依从于Spring的倡导为业务类定义一个接口：

　　代码 7 业务层操作接口

　　其中save(FileActionForm fileForm)方法，将封装在fileForm中的上传文件保存到数据库中，这里我们使用FileActionForm作为方法入参，FileActionForm是Web层的表单数据对象，它封装了提交表单的数据。将FileActionForm直接作为业务层的接口入参，相当于将Web层传播到业务层中去，即将业务层绑定在特定的Web层实现技术中，按照分层模型学院派的观点，这是一种反模块化的设计，但在"一般"的业务系统并无需提供多种UI界面，系统Web层将来切换到另一种实现技术的可能性也微乎其微，所以笔者觉得没有必要为了这个业务层完全独立于调用层的过高目标而去搞一个额外的隔离层，浪费了原材料不说，还将系统搞得过于复杂，相比于其它原则，"简单"始终是最大的一条原则。

　　getAllFile()负责获取T_FILE表所有记录，以便在网页上显示出来。

　　而getFileName(String fileId)和write(OutputStream os,String fileId)则用于下载某个特定的文件。具体的调用是将Web层将response.getOutputStream()传给write(OutputStream os,String fileId)接口，业务层直接将文件数据输出到这个响应流中。具体实现请参见错误！未找到引用源。节下载文件部分。

　　2、业务层接口实现类

　　FileService的实现类为FileServiceImpl，其中save(FileActionForm fileForm)的实现如下所示：

　　代码 8 业务接口实现类之save()

　　在save(FileActionForm fileForm)方法里，完成两个步骤：

　　其一，象在水桶间倒水一样，将FileActionForm对象中的数据倒入到Tfile对象中；

　　其二，调用TfileDAO保存数据。

　　需要特别注意的是代码的第11行，FileActionForm的fileContent属性为org.apache.struts.upload.FormFile类型，FormFile提供了一个方便的方法getFileData()，即可获取文件的二进制数据。通过解读FormFile接口实现类DiskFile的原码，我们可能知道FormFile本身并不缓存文件的数据，只有实际调用getFileData()时，才从磁盘文件输入流中获取数据。由于FormFile使用流读取方式获取数据，本身没有缓存文件的所有数据，所以对于上传超大体积的文件，也是没有问题的；但是，由于数据持久层的Tfile使用byte[]来缓存文件的数据，所以并不适合处理超大体积的文件（如100M），对于超大体积的文件，依然需要使用java.sql.Blob类型以常规流操作的方式来处理。

　　此外，通过FileForm的getFileName()方法就可以获得上传文件的文件名，如第21行代码所示。

　　write(OutputStream os,String fileId)方法的实现，如代码 9所示：

　　代码 9 业务接口实现类之write()

　　write(OutputStream os,String fileId)也简单地分为两个操作步骤，首先，根据fileId加载表记录，然后将fileContent写入到输出流中。

　　3、Spring事务配置

　　下面，我们来看如何在Spring配置文件中为FileService配置声明性的事务

　　Spring的事务配置包括两个部分：

　　其一，定义事务管理器transactionManager，使用HibernateTransactionManager实现事务管理；

　　其二，对各个业务接口进行定义，其实txProxyTemplate和fileService是父子节点的关系，本来可以将txProxyTemplate定义的内容合并到fileService中一起定义，由于我们的系统仅有一个业务接口需要定义，所以将其定义的一部分抽象到父节点txProxyTemplate中意义确实不大，但是对于真实的系统，往往拥有为数众多的业务接口需要定义，将这些业务接口定义内容的共同部分抽取到一个父节点中，然后在子节点中通过parent进行关联，就可以大大简化业务接口的配置了。

　　父节点txProxyTemplate注入了事务管理器，此外还定义了业务接口事务管理的方法（允许通过通配符的方式进行匹配声明，如前两个接口方法），有些接口方法仅对数据进行读操作，而另一些接口方法需要涉及到数据的更改。对于前者，可以通过readOnly标识出来，这样有利于操作性能的提高，需要注意的是由于父类节点定义的Bean仅是子节点配置信息的抽象，并不能具体实现化一个Bean对象，所以需要特别标注为abstract="true"，如第8行所示。

　　fileService作为一个目标类被注入到事务代理器中，而fileService实现类所需要的tfileDAO实例，通过引用3.2节中定义的tfileDAO Bean注入。

数据持久层

　　1、领域对象及映射文件

　　您可以使用Hibernate Middlegen、HIbernate Tools、Hibernate Syhchronizer等工具或手工的方式，编写Hibernate的领域对象和映射文件。其中对应T_FILE表的领域对象Tfile.java为：

　　代码 1 领域对象Tfile

　　特别需要注意的是：数据库表为Blob类型的字段在Tfile中的fileContent类型为byte[]。Tfile的Hibernate映射文件Tfile.hbm.xml放在Tfile .java类文件的相同目录下：

　　代码 2 领域对象映射文件

　　fileContent字段映射为Spring所提供的BlobByteArrayType类型，BlobByteArrayType是用户自定义的数据类型，它实现了Hibernate 的org.hibernate.usertype.UserType接口。BlobByteArrayType使用从sessionFactory获取的Lob操作句柄lobHandler将byte[]的数据保存到Blob数据库字段中。这样，我们就再没有必要通过硬编码的方式，先insert然后再update来完成Blob类型数据的持久化，这个原来难伺候的老爷终于被平民化了。关于lobHandler的配置请见本文后面的内容。

　　此外lazy="true"说明地返回整个Tfile对象时，并不返回fileContent这个字段的数据，只有在显式调用tfile.getFileContent()方法时才真正从数据库中获取fileContent的数据。这是Hibernate3引入的新特性，对于包含重量级大数据的表字段，这种抽取方式提高了对大字段操作的灵活性，否则加载Tfile对象的结果集时如果总是返回fileContent，这种批量的数据抽取将可以引起数据库的"洪泛效应"。

　　2、DAO编写和配置

　　Spring强调面向接口编程，所以我们将所有对Tfile的数据操作的方法定义在TfileDAO接口中，这些接口方法分别是：

　　·findByFildId(String fileId)

　　·save(Tfile tfile)

　　·List findAll()

　　TfileDAOHibernate提供了对TfileDAO接口基于Hibernate的实现，如代码 3所示：

　　代码 3 基于Hibernate 的fileDAO实现类

　　TfileDAOHibernate通过扩展Spring提供的Hibernate支持类HibernateDaoSupport而建立，HibernateDaoSupport封装了HibernateTemplate，而HibernateTemplate封装了Hibernate所提供几乎所有的的数据操作方法，如execute(HibernateCallback action)，load(Class entityClass, Serializable id)，save(final Object entity)等等。

　　所以我们的DAO只需要简单地调用父类的HibernateTemplate就可以完成几乎所有的数据库操作了。

　　由于Spring通过代理Hibernate完成数据层的操作，所以原Hibernate的配置文件hibernate.cfg.xml的信息也转移到Spring的配置文件中：

　　代码 4 Spring中有关Hibernate的配置信息

　　第3~9行定义了一个数据源，其实现类是apache的BasicDataSource，第11~25行定义了Hibernate的会话工厂，会话工厂类用Spring提供的LocalSessionFactoryBean维护，它注入了数据源和资源映射文件，此外还通过一些键值对设置了Hibernate所需的属性。

　　其中第16行通过类路径的映射方式，将sshfile.model类包目录下的所有领域对象的映射文件装载进来，在本文的例子里，它将装载进Tfile.hbm.xml映射文件。如果有多个映射文件需要声明，使用类路径映射方式显然比直接单独指定映射文件名的方式要简便。

　　第27~30行定义了Spring代理Hibernate数据操作的HibernateTemplate模板，而第32~34行将该模板注入到tfileDAO中。

　　需要指定的是Spring 1.2.5提供了两套Hibernate的支持包，其中Hibernate 2相关的封装类位于org.springframework.orm.hibernate2.*包中，而Hibernate 3.0的封装类位于org.springframework.orm.hibernate3.*包中，需要根据您所选用Hibernate版本进行正确选择。

　　3、Lob字段处理的配置

　　我们前面已经指出Oracle的Lob字段和一般类型的字段在操作上有一个明显的区别--那就是你必须首先通过Oracle的empty_blob()/empty_clob()初始化Lob字段，然后获取该字段的引用，通过这个引用更改其值。所以要完成对Lob字段的操作，Hibernate必须执行两步数据库访问操作，先Insert再Update。

　　使用BlobByteArrayType字段类型后，为什么我们就可以象一般的字段类型一样操作Blob字段呢？可以确定的一点是：BlobByteArrayType不可能逾越Blob天生的操作方式，原来是BlobByteArrayType数据类型本身具体数据访问的功能，它通过LobHandler将两次数据访问的动作隐藏起来，使Blob字段的操作在表现上和其他一般字段业类型无异，所以LobHandler即是那个"苦了我一个，幸福十亿人"的那位幕后英雄。

　　LobHandler必须注入到Hibernate会话工厂sessionFactory中，因为sessionFactory负责产生与数据库交互的Session。LobHandler的配置如代码 5所示：

　　代码 5 Lob字段的处理句柄配置

　　首先，必须定义一个能够从连接池中抽取出本地数据库JDBC对象（如OracleConnection，OracleResultSet等）的抽取器：nativeJdbcExtractor，这样才可以执行一些特定数据库的操作。对于那些仅封装了Connection而未包括Statement的简单数据连接池，SimpleNativeJdbcExtractor是效率最高的抽取器实现类，但具体到apache的BasicDataSource连接池，它封装了所有JDBC的对象，这时就需要使用CommonsDbcpNativeJdbcExtractor了。Spring针对几个著名的Web服务器的数据源提供了相应的JDBC抽取器：

　　·WebLogic：WebLogicNativeJdbcExtractor

　　·WebSphere：WebSphereNativeJdbcExtractor

　　·JBoss：JBossNativeJdbcExtractor

　　在定义了JDBC抽取器后，再定义lobHandler。Spring 1.2.5提供了两个lobHandler：

　　·DefaultLobHandler：适用于大部分的数据库，如SqlServer，MySQL，对Oracle 10g也适用，但不适用于Oracle 9i（看来Oracle 9i确实是个怪胎，谁叫Oracle 公司自己都说Oracle 9i是一个过渡性的产品呢）。

　　·OracleLobHandler：适用于Oracle 9i和Oracle 10g。

　　由于我们的数据库是Oracle9i，所以使用OracleLobHandler。

　　在配置完LobHandler后， 还需要将其注入到sessionFactory的Bean中，下面是调用后的sessionFactory Bean的配置：

　　代码 6 将lobHandler注入到sessionFactory中的配置

　　如第7所示，通过sessionFactory的lobHandler属性进行注入。

图 1 T_FILE表结构

图 2 SSH处理文件上传技术方案

图 3 文件上传页面

图 4 文件下载页面

图 5 工程资源结构

　　工程的类按SSH的层次结构划分为数据持久层、业务层和Web层；WEB-INF下的applicationContext.xml为Spring的配置文件，struts-config.xml为Struts的配置文件，file-upload.jsp为文件上传页面，file-list.jsp为文件列表页面。

　　本文后面的章节将从数据持久层-＞业务层-＞Web层的开发顺序，逐层讲解文件上传下载的开发过程。

　　首先事件是指从客户端页面（浏览器）由用户操作触发的事件，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模式，赶紧补课。