iLeichun

1.在tomcat下的webapps目录下新建一个文件夹java

2.在java下建立一个新文件夹WEB-INF(不能自定义)

3.在WEB-INF下建立一个新文件夹classes(不能自定义),这个目录下专门存放编译好的class文件,包括servlet

4.编写servlet
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class HelloWorld extends HttpServlet {
    public void doGet(HttpServletRequest request,
                      HttpServletResponse response) throws IOException, ServletException {
        response.setContentType("text/html");
        PrintWriter out = response.getWriter();
        out.println("");
        out.println("");
        out.println("Hello World!");
        out.println("");
        out.println("");
    }
}    
保存为HelloWorld.java

5.编译HelloWorld.java
使用命令javac HelloWorld.java,把编译好的class文件放到webappsjavaWEB-INFclasses目录下

6.编写web.xml文件

"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

    
        HelloWorld
        HelloWorld        
    

    
        HelloWorld
        /hello
    

保存为web.xml(不能自定义),把web.xml文件放到webappsjavaWEB-INF目录下

7.运行
启动tomcat服务器,在地址栏中输入http://localhost:8080/java/hello
 

如今，各种可用的Web框架如雨后春笋般林立。把浏览器指向Java技术网站时，常会看到新版的Web框架发布的消息，这些新框架意图改变现代世界。虽然有些人认为这是坏事，把Java群体分解得支离破碎，但事实是，不断冒出的新框架只是演化的过程而已。
通过这样的演化过程，有些框架成为目前几种主流的Web框架。本文着重讨论几种主流框架的原理，尤其详细讲解Structs框架，各框架之间的比较，及这些框架在未来发展的趋势。它们包括Structs框架，JavaServer Faces（JSF）框架，Spring框架。
这些框架几乎都是Model-View-Controller（MVC）模式的实现，所以本文先介绍了MVC的工作模式及其原理。Struts框架实质上就是在JSP Model2的基础上实现的一个MVC框架。在下面的章节中将详细介绍Struts框架的工作原理及流程。JSF是对Struts的升级。不过不同于Struts的开放源代码模式，它是Sun制定的一个规范。本文除了介绍JSF的工作原理，还有很大的篇幅对JSF，Struts的模式应用进行比较。Spring是另一个解决了许多在J2EE开发中常见的问题的强大框架。Spring的架构基础是基于使用JavaBean属性的Inversion of Control容器。然而，这仅仅是完整图景中的一部分：Spring在使用IoC容器作为构建所有架构层的完整解决方案方面是独一无二的。 Spring提供了唯一的数据访问抽象，包括简单和有效率的JDBC框架，极大的改进了效率并且减少了可能的错误。Spring的数据访问架构还集成了Hibernate和其他O/R mapping解决方案。
 

为什么 Spring 这么了不起？

     Spring 的创立者 Rod Johnson 以一种批判的眼光看待 Java™ 企业软件开发，并且提议很多企业难题都能够通过战略地使用 IOC 模式（也称作依赖注入）来解决。当 Rod 和一个具有奉献精神的开放源码开发者团队将这个理论应用于实践时，结果就产生了 Spring 框架。简言之，Spring 是一个轻型的容器，利用它可以使用一个外部 XML 配置文件方便地将对象连接在一起。每个对象都可以通过显示一个 JavaBean 属性收到一个到依赖对象的引用，留给您的简单任务就只是在一个 XML 配置文件中把它们连接好。

IOC 和 Spring

IOC 是一种使应用程序逻辑外在化的设计模式，所以它是被注入而不是被写入客户机代码中。将 IOC 与接口编程应用结合，就像 Spring 框架那样，产生了一种架构，这种架构能够减少客户机对特定实现逻辑的依赖。请参阅 参考资料 了解更多关于 IOC 和 Spring 的信息。



     依赖注入是一个强大的特性，但是 Spring 框架能够提供更多特性。Spring 支持可插拔的事务管理器，可以给您的事务处理提供更广泛的选择范围。它集成了领先的持久性框架，并且提供一个一致的异常层次结构。Spring 还提供了一种使用面向方面代码代替正常的面向对象代码的简单机制。

     Spring AOP 允许您使用拦截器 在一个或多个执行点上拦截应用程序逻辑。加强应用程序在拦截器中的日志记录逻辑会产生一个更可读的、实用的代码基础，所以拦截器广泛用于日志记录。您很快就会看到，为了处理横切关注点，Spring AOP 发布了它自己的拦截器，您也可以编写您自己的拦截器。



整合 Struts 和 Spring

    与 Struts 相似，Spring 可以作为一个 MVC 实现。这两种框架都具有自己的优点和缺点，尽管大部分人同意 Struts 在 MVC 方面仍然是最好的。很多开发团队已经学会在时间紧迫的时候利用 Struts 作为构造高品质软件的基础。Struts 具有如此大的推动力，以至于开发团队宁愿整合 Spring 框架的特性，而不愿意转换成 Spring MVC。没必要进行转换对您来说是一个好消息。Spring 架构允许您将 Struts 作为 Web 框架连接到基于 Spring 的业务和持久层。最后的结果就是现在一切条件都具备了。

     在接下来的小窍门中，您将会了解到三种将 Struts MVC 整合到 Spring 框架的方法。我将揭示每种方法的缺陷并且对比它们的优点。 一旦您了解到所有三种方法的作用，我将会向您展示一个令人兴奋的应用程序，这个程序使用的是这三种方法中我最喜欢的一种。

三个小窍门

     接下来的每种整合技术（或者窍门）都有自己的优点和特点。我偏爱其中的一种，但是我知道这三种都能够加深您对 Struts 和 Spring 的理解。在处理各种不同情况的时候，这将给您提供一个广阔的选择范围。方法如下：

使用 Spring 的 ActionSupport 类整合 Structs
使用 Spring 的 DelegatingRequestProcessor 覆盖 Struts 的 RequestProcessor
将 Struts Action 管理委托给 Spring 框架
装载应用程序环境

    无论您使用哪种技术，都需要使用 Spring 的 ContextLoaderPlugin 为 Struts 的 ActionServlet 装载 Spring 应用程序环境。就像添加任何其他插件一样，简单地向您的 struts-config.xml 文件添加该插件，如下所示：


  "org.springframework.web.struts.ContextLoaderPlugIn">
           "contextConfigLocation" value="/WEB-INF/beans.xml"/>

      




     前面已经提到过，在 下载 部分，您能够找到这三个完全可使用的例子的完整源代码。每个例子都为一个书籍搜索应用程序提供一种不同的 Struts 和 Spring 的整合方法。您可以在这里看到例子的要点，但是您也可以下载应用程序以查看所有的细节。

窍门 1. 使用 Spring 的 ActionSupport

    手动创建一个 Spring 环境是一种整合 Struts 和 Spring 的最直观的方式。为了使它变得更简单，Spring 提供了一些帮助。为了方便地获得 Spring 环境，org.springframework.web.struts.ActionSupport 类提供了一个 getWebApplicationContext() 方法。您所做的只是从 Spring 的 ActionSupport 而不是 Struts Action 类扩展您的动作，如清单 1 所示：


清单 1. 使用 ActionSupport 整合 Struts

package ca.nexcel.books.actions;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.ActionError;
import org.apache.struts.action.ActionErrors;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.DynaActionForm;
import org.springframework.context.ApplicationContext;
import org.springframework.web.struts.ActionSupport;
import ca.nexcel.books.beans.Book;
import ca.nexcel.books.business.BookService;
public class SearchSubmit extends ActionSupport {   |(1)
  public ActionForward execute(
    ActionMapping mapping,
    ActionForm form,
    HttpServletRequest request,
    HttpServletResponse response)
    throws IOException, ServletException {
    DynaActionForm searchForm = (DynaActionForm) form;
    String isbn = (String) searchForm.get("isbn");
  
    //the old fashion way
    //BookService bookService = new BookServiceImpl();
  
    ApplicationContext ctx =
      getWebApplicationContext();    |(2)
    BookService bookService =
      (BookService) ctx.getBean("bookService");   |(3)
  Book book = bookService.read(isbn.trim());
    if (null == book) {
      ActionErrors errors = new ActionErrors();
      errors.add(ActionErrors.GLOBAL_ERROR,new ActionError
        ("message.notfound"));
      saveErrors(request, errors);
      return mapping.findForward("failure") ;
  }
    request.setAttribute("book", book);
    return mapping.findForward("success");
  }
}
      




    让我们快速思考一下这里到底发生了什么。在 (1) 处，我通过从 Spring 的 ActionSupport 类而不是 Struts 的 Action 类进行扩展，创建了一个新的 Action。在 (2) 处，我使用 getWebApplicationContext() 方法获得一个 ApplicationContext。为了获得业务服务，我使用在 (2) 处获得的环境在 (3) 处查找一个 Spring bean。

     这种技术很简单并且易于理解。不幸的是，它将 Struts 动作与 Spring 框架耦合在一起。如果您想替换掉 Spring，那么您必须重写代码。并且，由于 Struts 动作不在 Spring 的控制之下，所以它不能获得 Spring AOP 的优势。当使用多重独立的 Spring 环境时，这种技术可能有用，但是在大多数情况下，这种方法不如另外两种方法合适。
 

去年火得不行的Spring框架，一般的书籍都会从IoC和AOP开始介绍起，这个IoC概念，个人感觉资料里都写得让人看得有些痛苦，所谓IoC，就是控制反转（Inversion of Control）的缩写，这个大家都知道，但是个人觉得理解这个概念，最好应该从依赖（dependence）开始讲起，以下观点由此展开：
    所谓依赖，举个例子说明，一个类Person，另一个类Car，如果Person的某个方法比如说drive，需要引用Car，则称Person类依赖于 Car类，延伸到对象，这种依赖关系依然成立，比如说Person类的对象boy依赖于Car类的对象toyota。再讲讲这个drive方法的实现，假定代码如下：
Public Person{
...
public void drive(){
  Car toyota=new Car("TOYOTA");
  toyota.挂档;
  toyota.踩油门;
  toyota.打方向;
}
}
    这其中的依赖关系，就导致了对象boy需要负责对象toyota的创建，甚至是整个生命周期的管理，而这样显然会带来耦合度高，不易维护等缺点，比如说要让这个男孩驾驶一辆Audi，则还需要修改类Person的代码。
    因此在java的设计理论中就提出了一条非常著名的原则，依赖倒转原则（Dependence Inversion），其核心思想就是要将这种具体类之间的依赖，尽量转换成抽象依赖，也就是说类Person应该依赖于抽象类ICar，而不是具体的类 Car，这里java就大力推荐了抽象和接口的使用，至于抽象和接口之间的区别，任何一本JAVA书籍都有介绍，这里就不再说了。

    这个依赖倒转原则在设计模式也体现得非常多，比如说工厂模式和构建模式，个人认为控制反转IoC，其实也可以认为是实现这个原则的一种设计模式。控制反转，其中的控制这个词一直不太理解是什么意思，不过控制反转的另外一种说法也就是依赖注入（dependence injection），个人觉得更易于理解。还是以上文的boy与toyota为例，其核心就是要将boy依赖的对象toyota注入到boy中去，而无需boy自己去引用toyota，这个注入的过程，通常是由一个控制程序来完成的，无需对象去关心，举例如下：
Public Person{
private ICar car;
public Person(ICar onecar){
  car=onecar;
}
public void drive(){
  car.挂档;
  car.踩油门;
  car.打方向;
}
}
    这个时候，进行注入并且调用的过程，就很简单了，如下：
Toyota toyota=new Toyota();
Person boy=new Person(toyota);
boy.drive();
    注：这里我们假定，Toyota类是ICar接口类的一个具体实现。
    这个例子就演示一个最简单的注入方式的例子，也就是构造子方式注入，通过将依赖对象注入到对象的构造子中来实现。另外还有一种常用的注入方式，就是属性方式注入，意思就是通过将依赖对象注入到对象的属性中来实现，还是以boy和toyota的例子说明，如下：
Public Person{
private ICar car;
public Person(){
}
public void drive(){
  car.挂档;
  car.踩油门;
  car.打方向;
}
public ICar getCar(){
  return this.car;
}
public void setCar(ICar onecar){
  car=onecar;
}
}
    这个时候，进行注入并且调用的过程，就变成如下所示：
Toyota toyota=new Toyota();
Person boy=new Person();
boy.setCar(toyota);
boy.drive();
    至此依赖注入的概念应该比较清楚了，再来看看在Spring中如何实现IoC的，看看Spring如何作为一个成熟的IoC容器，Spring中其实主要通过两个概念来实现IoC，首先通过XML配置文件，将对象和依赖对象都配置到某个XML文件中，当然该XML文件需要符合Spring指定的规范，然后通过架构中的BeanFactroy类，来自动实现上文所述注入过程，还是以boy与toyota为例，如下：
首先，Person类还是一样的，
然后xml配置文件增加点东西-（假定为bean.xml）：

    "http://www.springframework.org/dtd/spring-beans.dtd">

  
  
  
      
          
      
  

最后，调用的过程，就变成如下：
BeanFactory factory=new XmlBeanFactory("bean.xml");
Person boy=(Person )factory.getBean("onePerson");
boy.drive();
--不知是否讲清楚了，呵呵

 

作为基于MVC模式的Web应用最经典框架，Struts已经正式推出了1.1版本，该版本在以往版本的基础上，提供了许多激动人心的新功能。本文就将带你走进Struts1.1去深入地了解这些功能。
　　
　　说明：希望本文的读者能有一定的Struts使用基础。
　　
　　1、Model 2 Struts是基于Model 2之上的，而Model 2是经典的MVC（模型－视图－控制器）模型的Web应用变体，这个改变主要是由于网络应用的特性--HTTP协议的无状态性引起的。
　　
　　Model 2的目的和MVC一样，也是利用控制器来分离模型和视图，达到一种层间松散耦合的效果，提高系统灵活性、复用性和可维护性。在多数情况下，你可以将Model 2与MVC等同起来。
　　
　　在利用Model 2之前，我们是把所有的表示逻辑和业务逻辑都集中在一起（比如大杂烩似的JSP），有时也称这种应用模式为Model 1，Model 1的主要缺点就是紧耦合，复用性差以及维护成本高。
　　
　　2、Struts 1.1 和Model 2
　　
　　既然Struts 1.1是基于Model 2之上，那它的底层机制也就是MVC，首先，控制器（ActionServlet）进行初始化工作，读取配置文件（struts-config.xml），为不同的Struts模块初始化相应的ModuleConfig对象。比如配置文件中的Action映射定义都保存在ActionConfig集合中。相应地有ControlConfig集合、FormBeanConfig集合、ForwardConfig集合和MessageResourcesConfig集合等。
　　
　　提示：模块是在Struts1.1中新提出的概念，在稍后的内容中我们将详细介绍，你现在可以简单地把模块看作是一个子系统，它们共同组成整个应用，同时又各自独立。Struts1.1中所有的处理都是在特定模块环境中进行的。模块的提出主要是为了解决Struts1.0中单配置文件的问题。
　　
　　控制器接收HTTP请求，并从ActionConfig中找出对应于该请求的Action子类，如果没有对应的Action，控制器直接将请求转发给JSP或者静态页面。否则控制器将请求分发至具体Action类进行处理。
　　
　　在控制器调用具体Action的execute方法之前，ActionForm对象将利用HTTP请求中的参数来填充自己（可选步骤，需要在配置文件中指定）。具体的ActionForm对象应该是ActionForm的子类对象，它其实就是一个JavaBean。
　　
　　此外，还可以在ActionForm类中调用validate方法来检查请求参数的合法性，并且可以返回一个包含所有错误信息的ActionErrors对象。如果执行成功，ActionForm自动将这些参数信息以JavaBean（一般称之为form bean）的方式保存在Servlet Context中，这样它们就可以被其它Action对象或者JSP调用。
　　
　　Struts将这些ActionForm的配置信息都放在FormBeanConfig集合中，通过它们Struts能够知道针对某个客户请求是否需要创建相应的ActionForm实例。
　　
　　Action很简单，一般只包含一个execute方法，它负责执行相应的业务逻辑，如果需要，它也进行相应的数据检查。执行完成之后，返回一个ActionForward对象，控制器通过该ActionForward对象来进行转发工作。
　　
　　我们主张将获取数据和执行业务逻辑的功能放到具体的JavaBean当中，而Action只负责完成与控制有关的功能。遵循该原则，所以在上图中我将Action对象归为控制器部分。
　　
　　提示：其实在Struts1.1中，ActionMapping的作用完全可以由ActionConfig来替代，只不过由于它是公共API的一部分以及兼容性的问题得以保留。ActionMapping通过继承ActionConfig来获得与其一致的功能，你可以等同地看待它们。同理，其它例如ActionForward与ForwardConfig的关系也是如此。
　　
　　3、模块
　　
　　我们知道，在Struts1.0中，我们只能在web.xml中为ActionServlet指定一个配置文件，这对于我们这些网上的教学例子来说当然没什么问题，但是在实际的应用开发过程中，可能会有些麻烦。因为许多开发人员都可能同时需要修改配置文件，但是配置文件只能同时被一个人修改，这样肯定会造成一定程度上的资源争夺，势必会影响开发效率和引起开发人员的抱怨。Struts 1.1 在Struts 1.1中，为了解决这个并行开发的问题，提出了两种解决方案：
　　
　　1. 多个配置文件的支持
　　
　　2. 模块的支持
　　
　　支持多个配置文件，是指你能够为ActionServlet同时指定多个xml配置文件，文件之间以逗号分隔，比如Struts提供的MailReader演示例子中就采用该种方法。
　　
　　
　　
　　action
　　org.apache.struts.action.
　　ActionServlet
　　
　　 config
　　 /WEB-INF/struts-config.xml, /WEB-INF/struts-config-registration.xml
　　
　　
　　1
　　
　　
　　这种方法可以很好地解决修改冲突的问题，不同的开发人员可以在不同的配置文件中设置自己的Action、ActionForm等等（当然不是说每个开发人员都需要自己的配置文件，可以按照系统的功能模块进行划分）。
　　
　　但是，这里还是存在一个潜在的问题，就是可能不同的配置文件之间会产生冲突，因为在ActionServlet初始化的时候这几个文件最终还是需要合并到一起的。比如，在struts-config.xml中配置了一个名为success的，而在struts-config-registration.xml中也配置了一个同样的，那么执行起来就会产生冲突。
　　
　　为了彻底解决这种冲突，Struts 1.1中引进了模块（Module）的概念。一个模块就是一个独立的子系统，你可以在其中进行任意所需的配置，同时又不必担心和其它的配置文件产生冲突。因为前面我们讲过，ActionServlet是将不同的模块信息保存在不同的ModuleConfig对象中的。要使用模块的功能，需要进行以下的准备工作：
　　
　　1.为每个模块准备一个配置文件
　　
　　2.配置web.xml文件，通知控制器
　　
　　决定采用多个模块以后，你需要将这些信息告诉控制器，这需要在web.xml文件进行配置。下面是一个典型的多模块配置：
　　
　　
　　 config
　　 /WEB-INF/struts-config.xml
　　
　　
　　
　　 config/customer
　　 /WEB-INF/struts-config-customer.xml
　　
　　
　　
　　 config/order
　　 /WEB-INF/struts-config-order.xml
　　
　　
　　
　　要配置多个模块，你需要在原有的一个（在Struts1.1中将其对应的模块称为缺省模块）的基础之上，增加模块对应的。其中表示为config/XXX的形式，其中XXX为对应的模块名，中还是指定模块对应的配置文件。上面这个例子说明该应用有三个模块，分别是缺省模块、customer和order，它们分别对应不同的配置文件。
　　
　　3、准备各个模块所需的ActionForm、Action和JSP等资源
　　
　　但是要注意的是，模块的出现也同时带来了一个问题，即如何在不同模块间进行转发？有两种方法可以实现模块间的转发，一种就是在（全局或者本地）中定义，另外一种就是利用org.apache.struts.actions.SwitchAction。
　　
　　下面就是一个全局的例子：
　　...
　　
　　...
　　
　　 　　contextRelative="true"
　　path="/moduleB/index.do"
　　redirect="true"/>
　　...
　　
　　...
　　
　　
　　可以看出，只需要在原有的path属性前加上模块名，同时将contextRelative属性置为true即可。此外，你也可以在中定义一个类似的本地。
　　
　　
　　
　　 　　type="com.ncu.test.LoginAction"
　　name="loginForm"
　　scope="request"
　　input="tile.userLogin"
　　validate="true">
　　 　　contextRelative="true"
　　path="/moduleA/login.do"/>
　　
　　
　　
　　如果你已经处在其他模块，需要转回到缺省模块，那应该类似下面这样定义，即模块名为空。
　　
　　 　　contextRelative="true"
　　path="/login.do"/>
　　
　　此外，你也可以使用org.apache.struts.actions.SwitchAction，例如：
　　
　　...
　　
　　 　　type="org.apache.struts.actions.SwitchAction"/>
　　...
　　
　　...
　　
　　4、ActionServlet
　　
　　我们首先来了解MVC中的控制器。在Struts1.1中缺省采用ActionServlet类来充当控制器。当然如果ActionServlet不能满足你的需求，你也可以通过继承它来实现自己的类。这可以在/WEB-INF/web.xml中来具体指定。
　　
　　要掌握ActionServlet，就必须了解它所扮演的角色。首先，ActionServlet表示MVC结构中的控制器部分，它需要完成控制器所需的前端控制及转发请求等职责。其次，ActionServlet被实现为一个专门处理HTTP请求的Servlet，它同时具有servlet的特点

 

大家都知道，Struts是基于MVC模式的Web应用框架。Struts的优点之一就是将Web应用分成控制，模型和视图。模型中仅包含业务逻辑，视图中仅包含了显示逻辑。当我经过3次基于Struts开发web应用之后，对这一点有了一点感性的认识。

一、模型与视图的独立
　　所谓模型与视图的独立。实际上，就是要求我们在开发过程中，应该将模型组件和与视图有关的组件（一般是一些javabean）放在两个不同的包里。并且这两个包应该相互之间没有任何依赖关系。具体地讲就是这两个包相互都不能有导入。在视图组件这个包中除了包含javabean（通常用作DTO使用，将数据传向jsp），还应该包含一些键值的常量。因为DTO都是要存放在request范围里的，需要定义一些键值。由于这些键值是与视图密切相关的，所以不能够到处乱放，而是一定要放在视图组件包内。而模型组件包在开发过程中，你要完全抛开Struts和jsp，就当这些完全不存在，这样开发出来的模型组件即使将来换一个界面（例如：Swing）时，就可以很容易的重用。

二、控制的独立
　　首先，控制部分是由Struts软件提供的。Struts软件当然无法与你开发的视图和模型有依赖关系，因为Struts在开发的时候，你的模型和视图还没有开发出来呢。Strutst提供了Action这个父类，相当于提供了一个接口，所有具体的执行细节都由Action扩展类来实现。这样Struts框架将控制和控制的内容进行类分离，保证了控制与控制的内容（模型和视图）的独立性。 当然，你在开发模型和视图部分时也不要依赖控制部分，即，不要在你的软件包中导入org.apache.struts包及其子包中的类。只有这样才能真正保持MVC之间的独立性。

三、扩展Action类
　　前两点主要都在谈独立性。但是，一旦讲到扩展Action类，可以说所有的依赖关系都发生在这里。大家都知道，Action扩展类，负责调用模型和选择视图，那么当你在开发这些Action扩展类的时候，就需要导入模型组件包和视图组件包。也有是说Action依赖模型和视图。由于Action扩展类还有继承Action自类。Action类是控制的一部分，因为它位于org.apache.struts.action包中。所以Action扩展类还依赖控制组件。这样看来，Action扩展类仿佛是Struts这个框架中胶水，它依赖模型、视图和控制部分的组件，MVC这三个部分都是通过它来紧密联系在一起的。

四、总结
　　Struts框架强调MVC的独立，所以在开发时，视图组件、模型组件最好放在一个单独的包中，Action扩展类也放在一个单独的包里。Struts软件包、模型组件包和视图组件包应该相互隔离，彼此没有导入关系。而Action扩展类却依赖所有这三者。Action扩展类仿佛是胶水将MVC联系到了一起。

 

该版本主要是一些bugfix和文档的修正。在接下来的两周时间内，Hibernate主要工作还是对文档进行完善以及来自社区的bug报告，接下来还将发布一个 CR3 版本后，正式版本也将随即发布。

下载地址：http://sourceforge.net/projects/hibernate/files/hibernate3/

JavaScript 编程语言作为最流行的客户端脚本语言，深受Web开发人员爱戴。JavaScript语法灵活，简单易懂，对代码的格式的要求也相对松散。也正因为如此，JavaScript 的编码规范也往往被轻视，开发过程中修修补补，最终也就演变成为后续维护人员的恶梦。为了此种恶梦不再发生，IBM高级软件工程师王丹丹对JavaScript 编程语言的编码规范进行了总结，现转载于此，供大家学习。全文如下：

对于熟悉C/C++或Java语言的工程师来说，JavaScript显得灵活，简单易懂，对代码的格式的要求也相对松散。很容易学习，并运用到自己的代码中。也正因为这样，JavaScript的编码规范也往往被轻视，开发过程中修修补补，最终也就演变成为后续维护人员的恶梦。软件存在的长期价值直接与编码的质量成比例。编码规范能帮助我们降低编程中不必要的麻烦。而 JavaScript代码是直接发送给客户浏览器的，直接与客户见面，编码的质量更应该受到关注。

本文浅谈JavaScript编程中关于编码规范的问题，分析其中缘由。希望引起更多Web 开发人员对JavaScript编码规范问题的关注和对软件产品质量问题的重视。

 

二级缓存称为进程级缓存或SessionFactory级缓存，它可以被所有session共享，它的生命周期伴随着SessionFactory的生命周期存在和消亡。

第一步：复制ehcache.xml文件到src目录下，配置二级缓存

<defaultCache

maxElementsInMemory="100"  --设置缓存中的最大对象数

eternal="false"            --设置缓存中的对象是不是永不过期，如果设置为true，

timeToIdleSeconds和timeToLiveSeconds就没有意义了

timeToIdleSeconds="120"    --设置空闲时间，多少时间之内没有访问自动清除

timeToLiveSeconds="120"    --对象存活时间，一般情况下大于等于timeToIdleSeconds

diskPersistent="true"

overflowToDisk="true"      --将超出的对象存到硬盘上，存储位置设置，例如：<diskStore path="E:/cache"/>

/>

也可以配置某个特定对象的，如(但一般情况是使用缺省的就可以了)：

<cache name="uuser"

maxElementsInMemory="10000"

eternal="false"

timeToIdleSeconds="300"

timeToLiveSeconds="600"

overflowToDisk="true"

/>

第二步：启用二级缓存

1.启用二级缓存，默认是启用的：

<property name="cache.use_second_level_cache">true</property>

2.设置缓存产品，如：

<property name="cache.provider_class">org.hibernate.cache.EhCacheProvider</property>

3.指定哪些类使用二级缓存(两种方法)：

a.在hibernate.cfg.xml配置文件中定义

如：<class-cache class="lovo.po.User" usage="read-write"/>

b.在映射文件中定义

如：在<class>节点下：<cache usage="read-only"/>

有些类设置二级缓存，有些类不设置二级缓存；所以如果在映射文件中定义二级缓存的话会导致<cache>标签遍布在文件中，

因此常用第一种，即在hibernate.cfg.xml配置文件中定义，这样便于维护和管理。

第三步：二级缓存实例

1.打开两次session，调用load查询

代码部分：

Session session = this.sf.openSession();

User u1 = (User) session.load(User.class, 1);

System.out.println("用户姓名："+u1.getName());

//关闭seeion,释放一级缓存

session.close();

//重新开启session

session = this.sf.openSession();

User u = (User) session.load(User.class, 1);

System.out.println("用户姓名："+u.getName());

session.close();

 

执行部分：

如果设置<property name="cache.use_second_level_cache">false</property>，执行结果如下：

Hibernate:

select

user0_.id as id0_0_,

user0_.name as name0_0_,

user0_.password as password0_0_,

user0_.createTime as createTime0_0_,

user0_.expireTime as expireTime0_0_

from

t_user user0_

where

user0_.id=?

用户姓名：wangwu

Hibernate:

select

user0_.id as id0_0_,

user0_.name as name0_0_,

user0_.password as password0_0_,

user0_.createTime as createTime0_0_,

user0_.expireTime as expireTime0_0_

from

t_user user0_

where

user0_.id=?

用户姓名：wangwu

如果设置<property name="cache.use_second_level_cache">true</property>，执行结果如下：

Hibernate:

select

user0_.id as id0_0_,

user0_.name as name0_0_,

user0_.password as password0_0_,

user0_.createTime as createTime0_0_,

user0_.expireTime as expireTime0_0_

from

t_user user0_

where

user0_.id=?

用户姓名：wangwu

用户姓名：wangwu

可见，二级缓存是起作用了的。用get测试是同样的结果

2.在1的代码中加入this.sf.evict(User.class)，清除二级缓存中的对象，执行结果就跟设置了<property name="cache.use_second_level_cache">false</property>的效果相同。

当然也可以指定清除哪些对象：this.sf.evict(User.class,1)，结果很简单。

3.一级缓存和二级缓存的交互(CacheMode：CacheMode.NORMAL、CacheMode.PUT、CacheMode.GET)

代码部分：

Session session = this.sf.openSession();

//CacheMode.GET只向二级缓存中读数据不写

session.setCacheMode(CacheMode.GET);           ……1

User u1 = (User) session.load(User.class, 1);  ……2

//代码1和代码2顺序不能颠倒，否则CacheMode.GET对1号用户不起作用

System.out.println("用户姓名："+u1.getName());

session.close();

//重新开启session

session = this.sf.openSession();

User u = (User) session.load(User.class, 1);

System.out.println("用户姓名："+u.getName());

session.close();

执行结果：

Hibernate:

select

user0_.id as id0_0_,

user0_.name as name0_0_,

user0_.password as password0_0_,

user0_.createTime as createTime0_0_,

user0_.expireTime as expireTime0_0_

from

t_user user0_

where

user0_.id=?

用户姓名：wangwu

Hibernate:

select

user0_.id as id0_0_,

user0_.name as name0_0_,

user0_.password as password0_0_,

user0_.createTime as createTime0_0_,

user0_.expireTime as expireTime0_0_

from

t_user user0_

where

user0_.id=?

用户姓名：wangwu

 

默认情况下又读又写,即为CacheMode.NORMAL

CacheMode.PUT只写不读

在hibernate中，由于一级缓存的生命周期跟Session的生命周期一样，所以也可以理解为一级缓存是session缓存。
         一、通过在做查询的时候，有几个查询方法支持一级缓存，它们分别是：load(),get(),iterate(),其中要注意的是iterate方法只对实体对象查询才支持一级缓存，如果使用iterate来查询对象里面的相关属性，则查询的时候不支持一级缓存。
1、load()方法。
例子：
 

PS：只发出一条sql语句，虽然这里使用两次load方法，但是第一次load方法对于id为1的记录进行加载，到第3行才发出一条sql语句及符合的数据，这样就把数据放在一级缓存里面，在第4行开始继续使用load就从一级缓存里面抽取。

2、get()方法。
例子：
 

PS：跟1中load一样，只发出一条sql语句。

3、iterate()方法查询实体对象
例子：
 

PS：总共发出3条sql语句，1、2行发出两条语句，1条是查询实体对象的sql，另一条是查询实体对象的name属性，由于使用一级缓存，之前1、2行查询的实体存放在一级缓存里面，所以5、6行利用一级缓存里面的数据只发出一条查询id的sql。

4、iterate()方法查询实体对象属性（不支持一级缓存）
例子：
 

PS：由于iterate()方法查询实体对象属性，一级缓存不会产生作用，所以发出两条sql语句。

       二、一级缓存是存在的，所以要更加合理的管理好，提高程序的效率，通常都是通过clear(),evict()方法来清除缓存，当不需要使用一级缓存或者是更加高效率使用一级缓存。
              如果在一次性更新或者加入数量量比较大的情况下，更加要管理好一级缓存。
例子：
 

PS：在数据量比较大的情况下管理一级缓存的做法，一般都是设定一定数量的记录给更新或者保存等操作之后，避免一次性大量的实体数据入库导致内存溢出，所以才去先是用第8行的flush和第9行的clear方法来实现比较好的缓存管理。在数据量特别大的时候，可以使用jdbc来实现，因为 hibernate不太适合于数据量特别大的场合使用，如果连jdbc都满足不了数据量的效率要求，只好利用相关的数据库机制来实现。