了解 Ant 1.6 的新特性以及它们如何影响您组织编译过程的方式。

虽然 Ant 版本的 1.5.x 系列在任务级方面有很大的改善，但它没有改变人们使用 Ant 的方式。而 Ant 1.6 却有所不同。它增加了几个新特性，以支持大型或非常复杂的编译情况。但是，要充分利用它们的功能，用户可能需要稍微调整它们的编译过程。

本文重点介绍了其中的三种新特性 — <macrodef>、<import>、<subant> 任务，表明使用它们可以有什么收获，以及它们如何影响您组织编译设置的方式。

宏

大多数编译工程师迟早会面临必须执行相同的任务组合但在几个地方配置稍微有点不同的情况。一个常见的例子是创建一个web 应用程序存档，对于开发系统、测试系统和生产系统有着不同的配置。

让我们假设 web 应用程序拥有依赖于目标系统的不同的 web 部署描述符，并为开发环境使用了一个不同的 JSP 集合以及一个不同的资料库集合。配置信息将放在属性中，创建 web 存档的任务看起来将类似于

  <target name="war" depends="jar">
    <war destfile="${war.name}"
         webxml="${web.xml}">
      <lib refid="support-libraries"/>
      <lib file="${jar.name}"/>
      <fileset dir="${jsps}"/>
    </war>
</target>

其中 support-libraries 是引用一个在其它位置定义的 <fileset> ，该引用指向您的应用程序所需的附加资料库的一个公共集合。

如果您只想一次创建一个 web 存档，那么您只需要正确地设置属性。比如说，您可以从一个您的目标专有的属性文件中加载它们。

利用 Ant 1.5 创建存档

现在，假定您想为测试系统和生产系统同时创建存档，以确保您真正为两个系统打包了相同的应用程序。利用 Ant 1.5，您可能使用 <antcall> 来调用拥有不同属性设置的 "war" 目标，类似：

  <target name="production-wars">
    <antcall target="war">
      <param name="war.name" value="${staging.war.name}"/>
      <param name="web.xml" value="${staging.web.xml}"/>
    </antcall>
    <antcall target="war">
      <param name="war.name" value="${production.war.name}"/>
      <param name="web.xml" value="${production.web.xml}"/>
    </antcall>
</target>

当然，这假定两个目标系统都将使用相同的 jar 和 JSP。

但这种方法有一个主要缺点 — 就是速度慢。<antcall> 重新分析编译文件，并为每一次调用重新运行调用的目标所依赖的所有目标。在上面的例子中，"jar" 目标将被运行两次。我们希望这对第二次调用没有影响，因为 "war" 目标依赖于它。

利用 Ant 1.6 创建存档

使用 Ant 1.6，您可以忘掉用 <antcall> 来实现宏的方法，相反您可以通过参数化现有的任务来创建一个新的任务。因而上面的例子将变为：

  <macrodef name="makewar">
    <attribute name="webxml"/>
    <attribute name="destfile"/>
    <sequential>
      <war destfile="@{destfile}"
           webxml="@{webxml}">
        <lib refid="support-libraries"/>
        <lib file="${jar.name}"/>
        <fileset dir="${jsps}"/>
      </war>
    </sequential>
  </macrodef>

这定义了一个名称为 makewar 的任务，该任务可以和任何其它的任务一样使用。该任务有两个必需的属性，webxml 和 destfile。要使属性可选，我们必需在任务定义中提供一个默认值。这个示例假定 ${jar.name} 和 ${jsps} 在编译期间为常量，从而它们仍然作为属性指定。注意，属性在使用任务时展开而不是在定义宏的地方展开。

所用任务的特性几乎完全和属性一样，它们通过 @{} 而不是 ${} 展开。与属性不同，它们是可变的，也就是说，它们的值可以（并将）随着每一次调用而改变。它们也只在您的宏定义程序块内部可用。这意味着如果您的宏定义还包含了另一个定义了宏的任务，那么您内部的宏将看不到包含的宏的属性。

于是新的 production-wars 目标将类似于：

  <target name="production-wars">
    <makewar destfile="${staging.war.name}"
             webxml="${staging.web.xml}"/>
    <makewar destfile="${production.war.name}"
             webxml="${production.web.xml}"/>
</target>

这个新的代码段不仅执行得快一些，而且也更易读，因为属性名称提供了更多的信息。

宏任务还可以定义嵌套的元素。<makewar> 定义中的 <war> 任务的嵌套 <fileset> 可以是这种嵌套元素的一种。可能开发目标需要一些额外的文件或想从不同的位置中挑选 JSP 或资源。以下代码段将一个可选的嵌套 <morefiles> 元素添加到了 <makewar> 任务中

  <macrodef name="makewar">
    <attribute name="webxml"/>
    <attribute name="destfile"/>
    <element name="morefiles" optional="true"/>
    <sequential>
      <war destfile="@{destfile}"
           webxml="@{webxml}">
        <lib refid="support-libraries"/>
        <lib file="${jar.name}"/>
        <fileset dir="${jsps}"/>
        <morefiles/>
      </war>
    </sequential>
  </macrodef>

调用将类似于：

  <makewar destfile="${development.war.name}"
           webxml="${development.web.xml}">
    <morefiles>
      <fileset dir="${development.resources}"/>
      <lib refid="development-support-libraries"/>
    </morefiles>
  </makewar>

这就像 <morefiles> 的嵌套元素直接在 <war> 任务内部使用的效果一样。

即使迄今为止的示例仅显示了包装单个任务的 <macrodef>，但它不限于此。

下面的宏不仅将创建 web 存档，还将确保包含最终存档的目录在试图写入之前存在。在一个实际的编译文件中，您可能在调用任务之前使用一个设置目标来完成这个操作。

  <macrodef name="makewar">
    <attribute name="webxml"/>
    <attribute name="destfile"/>
    <element name="morefiles" optional="true"/>
    <sequential>
      <dirname property="@{destfile}.parent"
               file="@{destfile}"/>
      <mkdir dir="${@{destfile}.parent}"/>
      <war destfile="@{destfile}"
           webxml="@{webxml}">
        <lib refid="support-libraries"/>
        <lib file="${jar.name}"/>
        <fileset dir="${jsps}"/>
        <morefiles/>
      </war>
    </sequential>
  </macrodef>

这里注意两件事情：

首先，特性在属性展开之前展开，因此结构 ${@{destfile}.parent} 将展开一个名称包含了 destfile 特性的值和 ".parent" 后缀的属性。这意味着您可以将特性展开嵌入到属性展开中，而不是将属性展开嵌入特性展开中。

其次，这个宏定义了属性，该属性的名称基于一个特性的值，因为 Ant 中的属性是全局的并且不可改变。第一次尝试使用

      <dirname property="parent"
               file="@{destfile}"/>

相反将不会在 "production-wars" 目标中的第二次 <makewar> 调用产生期望的结果。第一次调用将定义一个新的名称为 parent 的属性，该属性指向父目录 ${staging.war.name}。第二次调用将查看这个属性但不会修改它的值。

预期 Ant 未来的版本将支持某些类型的限定范围的属性，这种属性只在宏执行期间定义。在此之前，使用特性的名称来构建属性名称是一种变通办法，潜在的副作用是要创建大量的属性。

提示：如果您查看您的编译文件时发现使用了 <antcall> 代替宏，那么强烈建议您考虑使用 macrodef 将其转换成真正的宏。性能影响可能非常显著，并且还可能产生更易读和更易于维护的编译文件。

导入

将一个编译文件分成多个文件有几个原因。

1. 文件可能变得太大，需要分成几个单独的部分，以便更易于维护。
2. 您有某个功能集是多个编译文件公用的，您想共享它。

共享公用功能/在 Ant 1.6 之前包含文件

在 Ant 1.6 之前，您唯一的选择是实体包含的 XML 方法，类似于：

  <!DOCTYPE project [
      <!ENTITY common SYSTEM "file:./common.xml">
  ]>
  
  <project name="test" default="test" basedir=".">
  
    <target name="setup">
      ...
</target>
  
    &common;
  
    ...
  
</project>

摘自 Ant 常见问题解答。

这种方法有两个主要的缺点。您不能使用 Ant 属性指向您想包含的文件，因此被迫在您的编译文件中对位置进行硬编码。您想包含的文件只是一个 XML 文件的一部分，它可能没有一个根元素，因而使用支持 XML 的工具进行维护更加困难。

共享公用功能/使用 Ant 1.6 包含文件

Ant 1.6 自带了一个名称为 import 的新任务，您现在可以使用它。上面的示例将变为

  <project name="test" default="test" basedir=".">
  
    <target name="setup">
      ...
</target>
  
    <import file="common.xml"/>
  
    ...
  
</project>

因为它是一个任务，因此您可以使用 Ant 所有的特性来指定文件位置。主要的差异是被导入的文件本身必须是一个有效的 Ant 编译文件，因而必须有一个名称为 project 的根元素。如果您想从实体包含转换到导入，那么您必须在导入的文件的内容首尾放上 <project> 标记；然后 Ant 将在读取文件时再次划分它们。

注意文件名称由 Ant 任务根据编译文件的位置（而不是指定的基本目录）确定。如果您没有设置项目的 basedir 属性或将其设为 "."，那么您将不会注意到任何差异。如果您需要根据基本目录解析一个文件，那么您可以使用一个属性作为变通办法，类似于：

  <property name="common.location" location="common.xml"/>
  <import file="${common.location}"/>

属性 common.location 将包含文件 common.xml 的绝对路径，并已根据导入项目的基本目录解析。

使用 Ant 1.6，所有的任务都可能放在目标之外或之内，除了两个例外。<import> 一定不能嵌入到目标中，<antcall> 一定不能在目标外使用（否则它将创建一个无限循环）。

而 <import> 可做的不仅仅是导入另一个文件。

首先，它定义了名称为 ant.file.NAME 的特殊属性，其中 NAME 替换为每一个导入文件的 <project> 标记的名称属性。这个属性包含了导入文件的绝对路径，导入文件可用来根据它自己的位置（而不是导入文件的基本目录）定位文件和资源。

这意味着 <project> 的名称属性在 <import> 任务环境中变得更加重要。它还用来为在被导入的编译文件中定义的目标提供别名。如果导入了以下文件

<project name="share">
    <target name="setup">
      <mkdir dir="${dest}"/>
</target>
</project>

导入编译文件可以查看作为 "setup" 或 "share.setup" 的目标。后者在目标覆盖的上下文中变得非常重要。

让我们假定有一个包含了多个独立的组件（每个组件拥有它自己的编译文件）的编译系统。这些编译文件几乎相同，因此我们决定将公用功能转移到一个共享和已导入的文件中。为了简单起见，我们只介绍 Java 文件的编译和创建结果的一个 JAR 存档。共享的文件将类似于

  <project name="share">
    <target name="setup" depends="set-properties">
      <mkdir dir="${dest}/classes"/>
      <mkdir dir="${dest}/lib"/>
</target>
    <target name="compile" depends="setup">
      <javac srcdir="${src}" destdir="${dest}/classes">
        <classpath refid="compile-classpath"/>
</javac>
</target>
    <target name="jar" depends="compile">
      <jar destfile="${dest}/lib/${jar.name}" basedir="${dest}/classes"/>
</target>
</project>

这个文件不会作为一个独立的 Ant 编译文件进行工作，因为它没有定义 "setup" 所依赖的 "set-properties" 目标。

组件 A 的编译文件可能类似于

  <project name="A" default="jar">
    <target name="set-properties">
      <property name="dest" location="../dest/A"/>
      <property name="src" location="src"/>
      <property name="jar.name" value="module-A.jar"/>
      <path id="compile-classpath"/>
</target>
    <import file="../share.xml"/>
</project>

它仅设置适当的环境，然后将全部的编译逻辑交给被导入的文件负责。注意该编译文件创建了一个空的路径作为编译 CLASSPATH，因为它是自包含的。模块 B 依赖于 A，它的编译文件将类似于

  <project name="B" default="jar">
    <target name="set-properties">
      <property name="dest" location="../dest/B"/>
      <property name="src" location="src"/>
      <property name="jar.name" value="module-B.jar"/>
      <path id="compile-classpath">
        <pathelement location="../dest/A/module-A.jar"/>
      </path>
</target>
    <import file="../share.xml"/>
</project>

您将注意到该编译文件与 A 的编译文件几乎一样，因此似乎有可能将大多数的 set-properties 目标也推送到 shared.xml 中。实际上，我们可以假定有一个对 dest 和 src 目标一致的命名惯例，以实现这一目的。

  <project name="share">
    <target name="set-properties">
      <property name="dest" location="../dest/${ant.project.name}"/>
      <property name="src" location="src"/>
      <property name="jar.name" value="module-${ant.project.name}.jar"/>
</target>

    ... contents of first example above ...
</project>

ant.project.name 是一个内置的属性，它包含了最外面的 <project> 标记的名称属性的值。因此，如果模块 A 的编译文件导入了 share.xml，那么它将拥有值 A。

注意，所有的文件都与导入编译文件的基本目录相关，因此 scr 属性的实际值依赖于导入文件。

为此，A 的编译文件将简单地变为

<project name="A" default="jar">
    <path id="compile-classpath"/>
    <import file="../share.xml"/>
</project>

B 的编译文件将变为

  <project name="B" default="jar">
    <path id="compile-classpath">
      <pathelement location="../dest/A/module-A.jar"/>
    </path>
    <import file="../share.xml"/>
</project>

现在假定 B 增加了一些 RMI 接口，需要在编译类之后但在创建 jar 之前运行 <rmic>。这就是目标覆盖能派上用场的地方。如果我们在导入编译文件中定义了一个目标，该目标与被导入的编译文件中的一个目标名称相同，那么将使用导入编译文件中的目标。例如，B 可以使用：

  <project name="B" default="jar">
    <path id="compile-classpath">
      <pathelement location="../dest/A/module-A.jar"/>
    </path>
    <import file="../share.xml"/>

    <target name="compile" depends="setup">
      <javac srcdir="${src}" destdir="${dest}/classes">
        <classpath refid="compile-classpath"/>
</javac>
      <rmic base="${dest}/classes" includes="**/Remote*.class"/>
</target>
</project>

在上面的示例中将使用 "compile" 目标，而不是 share.xml 中的目标；然而，不幸的是，这只是从共享那里复制 <javac> 任务。一种更好的解决方案是：

  <project name="B" default="jar">
    <path id="compile-classpath">
      <pathelement location="../dest/A/module-A.jar"/>
    </path>
    <import file="../share.xml"/>

    <target name="compile" depends="share.compile">
      <rmic base="${dest}/classes" includes="**/Remote*.class"/>
</target>
</project>

这只是使 B 的 "compile" 在原来的 "compile" 目标使用之后运行 <rmic>。

如果我们想在编译之前生成一些 Java 源代码（例如通过 XDoclet)，我们可以使用类似下面的方法：

    <import file="../share.xml"/>

    <target name="compile" depends="setup,xdoclet,share.compile"/>
    <target name="xdoclet">
       .. details of XDoclet invocation omitted ..
</target>

因此您可以完全覆盖一个目标或通过在原始目标之前或之后运行任务来增强它。

这里要注意一个危险。目标覆盖机制使导入编译文件依赖于在导入文件中使用的名称属性。如果任何人修改了导入文件的名称属性，那么导入编译文件将被破坏。Ant 开发社区目前正在讨论在 Ant 的一个未来的版本中为此提供一个解决方案。

提示：如果您在编译文件中发现了非常常见的结构，那么值得尝试将文件重构为一个（一些）共享文件，并在必要时使用目标覆盖。这可以使您的编译系统更加一致，并让您能够重用编译逻辑。

Subant

在某种意义上，subant 是两种任务合二为一，因为它了解操作的两种模式。

如果您使用 <subant> 的 genericantfile 属性，那么它的工作方式和 <antcall> 一样，调用包含任务的同一个编译文件中的目标。与 <antcall> 不同，<subant> 获取目录的列表或集合，并将为每一个目录调用一次目标，以设定项目的基本目录。如果您想在任意数量的目录中执行完全一样的操作，那么这非常有用。

第二种模式不使用 genericantfile 属性，而获取一个编译文件的列表和集合进行迭代，以在每一个编译文件中调用目标。这种工作方式类似于在一个循环中使用 <ant> 任务。

第二种形式的典型情景是几个能够独立编译的模块的一个编译系统，但是该系统需要一个主编译文件来一次性编译所有的模块。

在 Ant 1.6 之前构建主编译文件

在导入部分中讨论的例子使用了这样一个主编译文件。

  <target name="build-all">
    <ant dir="module-A" target="jar"/>
    <ant dir="module-B" target="jar"/>
</target>

在 Ant 1.6 之前的 Ant 中。

使用 Ant 1.6 构建主编译文件

在 Ant 1.6 中使用 <subant>，这可以重写为

 
  <target name="build-all">
    <subant target="jar">
      <filelist dir=".">
        <file name="module-A/build.xml"/>
        <file name="module-B/build.xml"/>
      </filelist>
    </subant>
</target>

这看起来并没有很大的改善，因为您仍然必须单独指定每一个子编译文件。相反如果您转用 <fileset>，那么情况将有所改观。

  <target name="build-all">
    <subant target="jar">
      <fileset dir="." includes="module-*/build.xml"/>
    </subant>
</target>

这将自动发现所有模块的编译文件。如果您增加了一个模块 C，主编译文件中的目标不需要修改。

但小心。与 <filelist> 或 <path>（也被 <subant> 支持）不同，<fileset> 是无序的。在我们的例子中，模块 B 依赖于模块 A，因此我们需要确保首先编译模块 A，而使用 <fileset> 没有办法这么做。

如果编译完全彼此独立或者它们对于一个给定的操作彼此独立，那么 <fileset> 仍然有用。模块 B 的文档目标可能完全不依赖于模块 A，同样还有从您的 SCM 系统中更新源代码的目标。

如果您想将编译文件的自动发现与根据编译的相互依赖性对编译进行排序结合在一起，那么您将必须编写一个定制的 Ant 任务。基本的想法是编写一个使用 <fileset> 的任务（让我们目前称之为 <buildlist>），确定依赖关系并计算 <subant> 必须使用的顺序。然后它创建一个以正确的顺序包含编译文件的 <path>，然后将对这个路径的一个引用放到项目中。调用将类似于

  <target name="build-all">
    <buildlist reference="my-build-path">
      <fileset dir="." includes="module-*/build.xml"/>
    </buildlist>
    <subant target="jar">
      <buildpath refid="my-build-path"/>
    </subant>
</target>

这个假想的 buildlist 任务已经在 Ant 用户邮件列表和 bug 跟踪系统中进行了讨论。很有可能 Ant 的一个将来的版本中将包含这样的一个任务。

在 Ant 1.6 中已经增加了大量的新特性。这些新功能中的许多功能使得编译模板易于创建、构造和定制。特别是 <import> 和 <target> 进行了覆盖。<import>、<macrodef> 和 <subant> 特性很有可能使得 Ant 编译可高度重用。<scriptdef>（本文中未讨论）对于需要一些脚本但不想用 Java 编写定制任务的人而言可能非常有吸引力。

${ math:gcd(10, 20) }

package demo.el;

public class MathTools {
    public static int gcd(int m, int n) {
        int r = 0;
        while(n != 0) {
            r = m % n;
            m = n;
            n = r;
        }
        return m;
    }
    
    public static double pi() {
        return Math.PI;
    }
}

<?xml version="1.0" encoding="UTF-8" ?>

<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-jsptaglibrary_2_0.xsd"
    version="2.0">
    
    <description>Math Tools</description>
    <tlib-version>1.0</tlib-version>
    <short-name>SimpleMathTools</short-name>
    <uri>/SimpleMathTools</uri>

    <function>
        <description>GCD Tool</description>
        <name>gcd</name>
        <function-class>demo.el.MathTools</function-class>
        <function-signature>int gcd(int,int)</function-signature>    
    </function>
    <function>
        <description>PI Tool</description>
        <name>pi</name>
        <function-class>demo.el.MathTools</function-class>
        <function-signature>double pi()</function-signature>    
    </function>

</taglib>

    <jsp-config>
        <taglib>
            <taglib-uri>http://www.caterpillar.onlyfun.net/phpBB2</taglib-uri>
            <taglib-location>/WEB-INF/tlds/mathtools.tld</taglib-location>
        </taglib>
    </jsp-config>

<%@taglib prefix="math" uri="http://www.caterpillar.onlyfun.net/phpBB2"%>
<html>
<body>
    Math Tools GCD Test: ${ math:gcd(100, 14) }<br>
    Math Tools PI Test: ${ math:pi() }
</body>
</html>

<html>
<body>
    Math Tools GCD Test: 2<br>
    Math Tools PI Test: 3.141592653589793
</body>
</html>

<%@taglib prefix="math" uri="/WEB-INF/tlds/mathtools.tld"%>

            if (valueList.getValueListInfo() != null && valueList.getList() != null
                  && valueList.getValueListInfo().getPagingNumberPer() < valueList.getValueListInfo().getTotalNumberOfEntries())
            {
               int start = (valueList.getValueListInfo().getPagingPage() - 1) * valueList.getValueListInfo().getPagingNumberPer();
               int end = Math.min(start + valueList.getValueListInfo().getPagingNumberPer(), valueList.getList().size());
               valueList = new DefaultListBackedValueList(valueList.getList().subList(start, end), valueList.getValueListInfo());
               if (LOGGER.isDebugEnabled())
               {
                  LOGGER.debug("The ValueList was paged by post process.");
               }
            }
         }

CacheElementInfo

该类用于封装所有的缓存统计信息（例如：命中数、不中数、命中比例等），用来监测在web应用中所有缓存对象的效率。

编译, 构建, 和单元测试

我用Ant创建了一个构建脚本来编译我的对象缓存框架的所有代码。Ant的构建脚本build.xml, 放在WEB-INF\classes 目录下。我还编写了Junit测试客户端来测试使用web门户缓存框架的不同缓存场景。测试脚本CachingTestCase, 放在WEB-INF\classes\common\caching\test 目录下。解压缩示例代码到一个新的web应用目录，如果要验证Junit测试脚本，从命令行运行以下命令：

切换当前目录到%TOMCAT_HOME%/webapps/web-app-name/WEB-INF/classes （在Unix测试环境中，目录应该是$TOMCAT_HOME/webapps/web-app-name/WEB-INF/classes）。

运行以下命令：

• ant common.compile
  编译缓存框架中所有的Java类。
• ant common.runjunit
  用于运行Junit测试脚本。测试脚本使用Log4J API来显示所有的输出信息。

考虑何时使用对象缓存的指导方针

当你决定要在你的web应用中缓存一些特定类别的数据的时候，请参照这些指导方针。缓存的应用应该经过谨慎地考虑，只有当其它方法，如：数据访问等，已经无法再进一步改进的时候才需要使用缓存。缓存将会带来复杂性，让维护工作变得更加复杂。因此，必须统筹考虑性能和缓存带来的复杂性的平衡关系。

当考虑使用缓存的时候，需要考虑对象的预定执行时间和刷新率或者叫做对象的生存时间。缓存不能容纳所有我们想要存储的数据，因此缓存使用的内存及时得到释放，即可以通过定义合理的生存时间实现，也可以在数据不再需要的时候显式地释放被缓存的对象。可以指定缓存算法如最近被访问算法（LRU）或者最少被使用算法（LFU）以便缓存基于访问频率来释放对象。Jack Shirazi的著作 Java 性能调整 提供了一个关于缓存主题的非常有趣的讨论，讨论了什么类型的数据应该被缓存，以及何时使用缓存的建议。

注意缓存框架并没有处理在web应用中需要被缓存的对象的创建（例如：从数据源检索数据的数据访问逻辑并没有在缓存类中编写）。这要依赖于客户程序来定义真正的数据访问逻辑。像Java数据对象等技术通常用于在企业级web应用中封装数据访问逻辑。参考O'Reilly的 Java 数据对象 来学习更多的关于如何将数据访问层与业务逻辑层分离的知识。

结论

本文提供了对使用Jakarta的Java缓存系统（JCS）来为web门户应用开发对象缓存框架的概要介绍。该框架非常稳定并可以被重用于其它任何web应用，甚至可以用于客户/服务器模式的Java应用程序。本文详细介绍了web门户缓存框架的工作原理，并提供了Junit测试脚本来对不同场景的缓存框架进行测试。

JCS was built as a system close to JCACHE Java Temporary Caching API (JSR-107), a description of the caching system used in Oracle 9i and other popular caching frameworks. 该规范可能会在将来的JDK发行版本中作为一种Java扩展框架。我的其中一个目的就是让web门户缓存框架与JCS保持松散耦合。这样的话，如果我将来需要转换到另一种框架（例如Jcache），我可以在对web门户应用客户程序代码不做大的调整的情况下完成切换。

我现在通过记录缓存监测信息的日志（使用Log4J API）如：命中数、不中数、命中率来衡量缓存的效率。可能将来有其它参数需要被监测来衡量缓存的效率。同样的，用来测量使用或不使用缓存对数据访问的反馈时间，应该使用一些负载测试工具如：Grinder或者Jmeter来测试其伸缩性和性能效果。

在机群环境下保持缓存同步将是一个挑战，因为每个servlet容器将会在自己的JVM中拥有一个缓存管理器实例。解决该问题的方法就是创建消息驱动Bean（MDB）在需要刷新数据的时候通知所有的缓存管理器。

通常的对象查找方法，如：简单的Hashtable、JNDI甚至是EJB，提供了在内存中存放对象并通过键值查找对象的方法。但是任何一种方法都没有提供当对象不需要的时候从内存中移出的机制，或者当访问对象迟于对象存放期限的时候自动创建对象的机制。HttpSession 对象 (in the servlet package) 也允许对象被缓存，但是它没有共享、失效、单一对象存放期满、自动装载或者spooling 这些缓存框架需要具备的基础机制。

虽然将缓存功能集成到web应用中需要额外的设计和开发工作，但我认为缓存带来的利益大于额外付出的工作。我已经看到在我实现了缓存框架之后 ，我的web应用的性能有很大的提高，特别是在访问静态数据和查找结果方面。该web应用模块目前处于测试阶段。在不久的将来，我会提供一些性能方面的测试数据（包括使用与不使用缓存的情况）来比较缓存如何帮助设计更快、更具伸缩性的web应用。

示例代码

• cachingcode.zip

参考资源

• Java 性能调整, Jack Shirazi, O'Reilly
• JCS 主页
• JCache API
• OSCache
• SpiritCache
• Commons Collections
• Coherence
• Object Caching Service for Java

Srini Penchikala 是一名软件咨询顾问，当前为Computer Consultants of America, Inc. 工作。

http://www.hibernate.org/209.html

Some Parent-Child Principles

Getting Parents and Children to Play Nice

If you browse the Hibernate Discussion forum http://forum.hibernate.org you'll notice that about 50% of the questions are answered by RTFM, referencing the Parent/Child example in chapter 16 of the Hibernate Reference http://www.hibernate.org/hib_docs/reference/en/html.

In addition, here are some of the basic principles and pitfalls I've discovered, along with an example. Corrections are most welcome ... this is a repost from our internal blog

First ... the situation. Let's use two classes called ParentClass and jobs as an example

We have (pseudocode):

ParentClass {
     Set jobs;
}

as our parent, and:

ChildJobClass implements GenericJob {
     ParentClass parent;
}

as our child.

One context can have zero to many jobs, hence the set of jobs. One notification has but one parent.

PRINCIPLE 1: Your job is to set up native object references

1. All the references in these classes are object references. The most common place to go wrong is trying to manage object references as pointers or integers in your code. Don't do that! Translating the object references into serialized pointers is Hibernate's job. Your job is to make sure the native Java structures are correct on an object level, e.g. that ParentClass contains a real live set of ChildJobClass objects, not their ID's, and that ChildJobClass objects have a real live parent object which is an instance of the ParentClass class.

2. Next, keep in your mind the idea that, while you do not manage the relational mapping of the object references, you do need to manage the object reference itself. You must go beyond declaring ParentClass parent and actually make a call to *ChildJobClass.setParent(myParentClass) * in your code. This is mostly done at construction time, so you'll probably have a constructor like this:

    public ChildJobClass (ParentClass thisParent)
    {
        setParent(thisParent);
    }

Note that the class that is constructing the notification is responsible for passing in a valid parent ParentClass to the constructor. Note also that the constructor itself is responsible for assigning that parent ParentClass to the parent property of the ChildJobClass. Fail either step and you'll get "cannot insert" or not null integrity constraint problems.

Principle 2: Hibernate's job is to read *.hbm.xml maps and translate your object references into crossreferences in the database

This means that your code does not (at the risk of being redundant) mess around with integer values representing object identifiers. Each of your mapped objects will have an identifier, complete with getter and setter, but unless you move into special features of the id mapping (and you should not!), you do not actually call those setters and getters. Hibernate does.

All your help to Hibernate comes in the area of mapping, e.g. *.hbm.xml files. That's where you inform hibernate of the structure of your objects and how that structure maps to database tables and columns

Principle 3: Most parent-child relationships should be mapped as bidirectional

Generally speaking you'll want parent objects to have their kids in place when constructed and child objects to have their parents when constructed. If you're concerned about overhead you can defer the construction of the references to the moment they are needed using lazy initialization, outside the scope of this note. The most common form of bidirectional parent child mapping is the Basic Collection pattern, which maps one parent to many children, many children to one parent. You can also do many-to-many on the child side -- see the excellent Index of Relationships http://www.xylax.net/hibernate/ page for examples. We'll deal with basic here.

In the Basic Collection pattern the mapping works like this:

1. The parent maps the set containing the children to the appropriate child table as a one-to-many relationship, e.g. one parent to many children.

2. The parent marks the relationship as "inverse". This attribute says that the parent doesn't actually update the relationship; the child updates the relationship. We do this so that we can deal with "NOT NULL" constraints on the child side.

So far our parent-side mapping looks like this:

 <set name="jobs" table="GENERIC_JOB" lazy="false" cascade="all" inverse="true" >
   <key column="PARENT_ID"/>
   <one-to-many class="org.mitretek.MyApplication.workflow.job.ChildJobClass"/>
 </set>

Which says:

• The property of the parent object is called jobs, and is a set class
• The objects in the jobs set are stored in the GENERIC_JOB table
• Hibernate uses the PARENT_ID column of the GENERIC_JOB table to store the identifier of the parent object
• The class to be stored in the GENERIC_JOB table is the ChildJobClass class

The class property might give you pause ... you might expect a GenericJob class. Ordinarily you'd be right; in our specific example GenericJob is really an interface that ChildJobClass and a few other classes implement, and you're looking at a polymorphic persistence situation. We'll address that later. Pretend you entered the ChildJobClass table if you want.

3. On the child end, map the child back to the parent using a many-to-one relationship. This relationship actually manages the link to and from parent.

    <many-to-one name="parent" class="org.mitretek.MyApplication.workflow.ParentClass" column="parent_id" not-null="true" />

There are a few things to note in this simple snip of mapping:

• The many-to-one mapping is instead of a <property .../> mapping for the parent property, not along with!
• The name attribute lists the name of the property of the child where the parent is inserted. As we said earlier, this is done by getters and setters on the child, and a genuine Java property of the appropriate parent class in the child object. Be sure to put a parent object in the property at construction or another appropriate time before persistance

• The parent_id column must exist in the child table. The child table isn't referenced because the class that is being mapped (it happens to be in GenericJob.hbm.xml) has already indicated tables.

• Not null is enforced here.

That's pretty much it. At persistance time, assuming you're persisting a ParentClass with a few ChildJobClasss nested in a set property the following activities happen (not necessarily in order):

• Hibernate notices from the parent mapping that the jobs need to be mapped to the GENERIC_JOB table using the PARENT_ID column of GENERIC_JOB, but that the actual maintenance of the insert is done from the child end.

• Hibernate notices from the child mapping that the object being mapped to the GENERIC_JOB table is called this.parent, and that its ID indeed goes into the PARENT_ID column, and furthermore it must not be null

• Hibernate transacts enough SQL to get identifiers for any not-yet-persisted objects. This is the big reason you don't mess directly with identifiers.

• Hibernate persists the parent and automatically persists its kids in the same transaction, being sure to set the parent's identifier in the parent_id field of the child so that it can be reconstituted in a future query.

Principle 4: Deal with Polymorphic Persistence from the superclass and the subclass will take care of itself

We mentioned earlier that GenericJob was really an interface that ChildJobClass and a bunch of other classes implement for different job types. We used the table-per-subclass mapping strategy for this, which is outside the scope of this note, except to point out that the strategy implements as a join from a superclass GENERIC_JOB table which contains the properties of the interface or top level class, to each subclass table, such as NOTIF_JOB for notification jobs.

The point here is that you do not deal directly with the subclass tables -- that too is Hibernate's job. Deal with the top-level table but indicate which underlying class is being persisted. Hibernate will extend the record across the join automatically.

For that reason we mapped our notification to the GENERIC_JOB table but indicated it was implemented as a ChildJobClass.

Hibernate stored the interface attributes in GENERIC_JOB and the child-specific nonInterface attributes in the NOTIF_JOB table.

Maybe you'd eliminate 50% of the RTFMs if you'd put this content into
the reference manual. This fills in lots of gaps.

I am trying to do an insert in the parent and child with no 
Referrential integrity. Hibernated inserts a row in the parent table 
and in the child but it puts 0 in the FK column in the child table. I 
have checked eveything and I could not find any problems with the code 
and the mapping.

Also when I try to insert multiple child rows in the db, Hibernate 
throws NonUniqueObjectException.

Any ideas? Is it because no physical FK constraints have been defined.
Thanks.

HyperJAXB - relational persistence for XML objects with JAXB and Hibernate

What is HyperJAXB?

HyperJAXB is an add-on for Sun's reference implementation of JAXB (Java Architecture for XML Binding). It provides JAXB objects with relational persistence layer using Hibernate.

What can I do with HyperJAXB?

HyperJAXB eases usage of XML with relational databases. With HyperJAXB you can combine JAXB and Hibernate to implement one of the following target usage scenarios:

• load (unmarshal) object structure from XML document and save (persist) these objects in a relational database;
• load objects from a relational database and present (marshal) loaded objects in XML form;
• query relational database using HQL and present query results in XML.

How it works?

JAXB is basically a code generation engine. It accepts a schematic definition of you XML documents (usually in the form of an XML Schema) as input and generates source code of XML-enabled classes. HyperJAXB augments generated code by adding Hibernate XDoclet annotations. Added annotations effectively define Hibernate O/R mapping for the generated classes.

Combination of JAXB RI, HyperJAXB and Hibernate toolset allows you automatically generate the following artifacts out of you XML Schema:

• source code of XML-enabled objects with Hibernate XDoclet annotations;
• object/relational mapping for Hibernate;
• database schema for the target database.

Please see the reference for more information.

A code example?

Unmarshalling and saving:

// Unmarshall the document
final MyObject myObject = (MyObject) unmarshaller.unmarshal(document);

// Open the session, save object into the database
final Session saveSession = sessionFactory.openSession();
// Save id for the later use
final String id = saveSession.save(myObject);
saveSession.flush();
// Close the session
saveSession.close()

Loading and marshalling:

// Open the session, load the object
final Session loadSession = sessionFactory.openSession();
final MyObject myLoadedObject = (MyObject) loadSession.load(MyObject.class, id);
loadSession.close();

// Marshall loaded object into the document
final Document loadedDocument = documentBuilder.newDocument();
marshaller.marshal(myLoadedObject, loadedDocument);

Mapping generated by HyperJAXB ensures that document and loadedDocument are identical.

Where can I find it?

Check out this project on https://hyperjaxb.dev.java.net.

http://blog.ideoplex.com/software/2003/12/11.html

Adding a Hibern8IDE browser to your Hibernate Project

The Hibern8 IDE is a quick'n'dirty interactive Hibernate Query Language (HQL) tool. And while it's not really an IDE, it's a pretty slick way of viewing the contents of your persistent Hibernate data store. There are basically two ways of opening up your data store with Hibern8IDE: you can interactively add hibernate properties and configuration files or you can programmatically start Hibern8IDE with a hibenate configuration object. Since I hate to constantly repeat myself, I opted for the programmatic option.

If you've been following my series on Hibernate, then you know that I've been keeping all my configuration files in the cfg directory tree. So I decided to simply traverse the cfg directory tree, adding all .hbm.xml files to a configuration object before passing the configuration object on to Hibern8IDE. And since traversing a directory is a pretty common operation, I decided to implement a general solution consisting of a simple TreeWalker class and a TreeAction interface.

14 May 04: Max Andersen from the Hibernate team comments that the load order of .hbm.xml files is important when a subclass or joined-subclass is defined in a separate file from the parent. If the parent is defined in parent.hbm.xml and the child is defined in child.hbm.xml, then parent.hbm.xml must be loaded before child.hbm.xml.

package util; 
 
public interface TreeAction {
    public void handle( java.io.File f );
}

package util;
 
import java.io.File;
 
public class TreeWalker {
 
    public void walk ( TreeAction actor, File root )
    {
        if ( root.exists() ) {
            if ( root.isDirectory() ) {
                File[] files = root.listFiles();
 
                for ( int i=0 ; i<files.length ; ++i ) {
                    if ( files[i].isDirectory() ) {
                        this.walk( actor, files[i] );
                    }
                    else if ( files[i].isFile() ) {
                        actor.handle( files[i] );
                    }
                }
            }
            else if ( root.isFile() ) {
                actor.handle( root );
            }
        }
    }
}

The top level Ide class treats each command line argument as a configuration root directory It contains a static inner class Action implementing TreeAction that adds each .hbm.xml file to the hibernate configuration. And we hand the configuration object to Hibern8IDE once all the configuration directories have been traversed.

Note that static inner class Action has to catch the hibernate MappingException to match the TreeAction interface. After catching the MappingException, we use it to create a RuntimeException. This trick of wrapping checked exceptions in a RuntimeException comes courtesy of Tim Bray. This is an appropriate response because our only other choice is to ignore it entirely.

import java.io.File;
 
import net.sf.hibernate.cfg.Configuration;
import net.sf.hibernate.MappingException;
import net.sf.hibernate.HibernateException;
 
import net.sf.hibern8ide.Hibern8IDE;
 
import util.*;
 
public class Ide {
 
    static class Action implements TreeAction {
        private Configuration config;
 
        public Action ( Configuration aConfig )
        {
            config = aConfig;
        }
 
        public void handle ( File f )
        {
            String name = f.toString();
            if ( name.endsWith( ".hbm.xml" ) ) {
                try {
                    config.addFile( f );
                } catch ( MappingException e ) {
                    throw new RuntimeException( e );
                }
            }
        }
    }
 
    public static void main ( String[] args )
        throws MappingException,
               HibernateException
    {
        Configuration cfg = new Configuration();
        Action      actor = new Action( cfg );
        TreeWalker walker = new TreeWalker();
 
        for ( int i=0 ; i<args.length ; ++i ) {
            File f = new File( args[i] );
            walker.walk( actor,f );
        }
 
        Hibern8IDE.startWith( cfg );
    }
}

Finally, we add a new ide action to our build file (other minor buildfile changes not shown here). The single command line argument references our configuration directory.

  ...
  <target name="ide" depends="compile,setup-run">
    <java classname="Ide"
          fork="true">
      <classpath refid="classpath.ide" />
      <arg value="${cfg-dir}" />
      <sysproperty key="log4j.configuration" value="${LOG4J_OUT}" />
    </java>
  </target>
  ...

Now we can launch the Hibern8IDE query tool by simply typing "ant ide". Here's the source for adding a Hibern8IDE query tool to your Hibernate project..

Disclaimer: I don't claim to be an expert on hibernate. Please send comments and corrections.

http://joe.truemesh.com/squiggle/

user(group)--AccessI(访问级别)---resources(各种资源)

一行就是一个ACL记录。基于这种原理，opensymphony开发了两个框架：OSUser ,OsAccess。都是很优秀的框架，可以去参考一下。

ACL缺点：

用数据的格式硬性限定权限管理，失去灵活定制的功能。

ACL以resource，user为主。

抽象不大合理。ACL本身是一个抽象吗？值得探讨。现实世界中，一个人具备一些权限，这些权限可以操作特定资源。那我们的抽象就应该是user本身关联着权限，关联的箭头由User指向权限，然而ACL中的User与权限的关联却是被动的关联。

ACL本身不适合反映用户组（机构）权限继承关系。

在OA场合中，也不适合使用ACL。

接下来，我们探讨一下基于role的权限的管理设计。

引用一篇java道上的一片帖子：

作者：dunel  出自：http://www.jdon.com

最近对就有系统人员权限升级计划——也谈人员权限的设计。 dunel http://www.jdon.com Apr 16, 2004 5:43 PM 回复 前言： 人员、机构、角色、权限对象间组织关系的重新抽象； 人员、机构、角色、权限； 这四个经过抽象的对象原型经过事实证明还是比较成功的； 这几个对象不会有大的变动； 但是实际中也碰到了问题，就是这些对象之间关系的不确定性； 下面描述以下四个对象新的关系结构； 1 核心思想： 1。人员在系统中总是扮演某种角色的； 例如：小张在属于办公厅这个部门，以前我们都倾向于认为办公厅聚合了小张。 其实考察一下实际情况，办公厅下面有个办公厅人员这个角色，而小张只是扮演了这个角色而已； 考虑一下如果当小长被调动另外一个部门时候那种抽象更容易处理。 2。业务逻辑希望面对的是系统中的角色，而非扮演角色的具体的人。 例如：以工作流示例，一个公文的下一步流转的对象是组织部部长，他不关心谁扮演这个部长，人员权限模块知道就行了。 2 抽象关系描述： .人员和机构之间的松耦合（通过角色耦合） 目的：改变糟糕地人员和机构之间的强聚合关系。 人员和部门通过角色进行耦合； 人员和部门的关系可以容易的变化，不会产生大的影响。 .人员和角色间变成强聚合关系； 目的：强调人员在系统中必须扮演角色，起码扮演某个机构的人员这个角色； 人员的角色又可以同时扮演的，也有互相排斥的。 排斥的角色就是不能同时扮演的，登录以后可以选择的角色； 由管理员规定人员的那些角色是相互排斥的； .机构和权限点之间没有直接关系； 目的：让机构的抽象更清晰化，机构和权限的关系通过角色体现； .机构和角色之间强聚合关系； 目的：明确部门的作用是行使某种特定职能的。 说明： 部门和部门之间还有从属关系； 部门可以专门设置部门管理员用于管理下级的机构和人员，使分级管理在模型上成为可能； 部门拥有的角色有写是系统规定的，如：部门人员，部门管理员； 部门可以自定义自己的角色，并由部门管理员管理； .角色之间的继承关系； 目的：更好的处理角色和权限点之间的关系； 说明： 角色之间拥有继承关系如上图所示。 可以被继承的角色是由系统管理员制定的，部门管理员不能制定； 3 总结： 经过考虑，我认为 人员、机构、角色、权限 的关系应该做成可以改变的插件，系统初始时候进行选择不同组织方式； 也就是说，上文描述的 人员、机构、角色、权限 的关系还有原有关系都做成的插件，并不抛弃原有的人员权限关系。

Re: 最近对就有系统人员权限升级计划——也谈人员权限的设计。 发表时间: Apr 16, 2004 5:46 PM 回复 发表人: dunel    发表文章: 13 / 注册时间: 2004-04

Re: 最近对就有系统人员权限升级计划——也谈人员权限的设计。 发表时间: Apr 16, 2004 5:53 PM 回复 发表人: dunel    发表文章: 13 / 注册时间: 2004-04 与RBAC向做的设想就是人员和权限的直接耦合关系。 在应用中经常会出现某个人就是要比其他人多出来一个权限，而且这样的情况非常多，如果每次都为这种情况做一个角色的话，基本上会造成角色的泛滥。 不知道大家有什么好的设想，或者解决方案。

Re: 最近对就有系统人员权限升级计划——也谈人员权限的设计。 发表时间: Apr 19, 2004 4:32 PM 回复 发表人: dunel    发表文章: 13 / 注册时间: 2004-04 最近研究了RBAC的规范，RBAC没有提到关于人员是如何组织的，更关注与资源的控制。但是我认为人员机构的管理是应该一起关注的，所以做出了这样的设计。 大家给提提意见吧。

Re: 最近对就有系统人员权限升级计划——也谈人员权限的设计。	发表时间: Apr 20, 2004 1:28 PM	回复
发表人: dunel    发表文章: 13 / 注册时间: 2004-04
ROLE BASE ACCESS CONTROL 最近研究了RBAC的标准，这个标准刚刚成为美国国家标准。http://csrc.nist.gov/rbac/ 下面是我的一些心得和笔记，希望能有用处。 1. RBAC的中心思想就是通过角色来做到用户和权限点的关联； 2. 扩展RBAC角色是可以继承的。 一般继承，就是多继承，一个角色可以继承多个角色； 限制继承就是单继承，一个角色只能继承一个角色； 3. 静态职责分离Static Separation of Duty --SSD是说，一个人一次只能扮演一个角色； 经常在系统的行政角色上实施SSD；这个限制强加在人员分配的情况下的； 4. 动态职责分离 Dynamic Separation of Duty – DSD就是：timely revocation of truest,就是能给人员分配冲突的角色，但是一个人每次只能扮演其中的一个；原来的设想中涉及到了DSD就是让人选择角色进入；

我们看看一个XML实现：

user.xml:－－－》对应role权限系统中的参与者。

<?xml version="1.0" encoding="UTF-8"?>
<users>
  <user id="superuser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
    <attributes>
      <attribute name="firstname" value="superuser"/>
      <attribute name="password" value="secret"/>
    </attributes>
  </user>
  <user id="bob">
    <roles>
      <role id="portal.user"/>
      <role id="portal.it"/>
    </roles>
    <attributes>
      <attribute name="firstname" value="Bob"/>
      <attribute name="password" value="bob1"/>
    </attributes>
  </user>
  <user id="alice">
    <roles>
      <role id="portal.user"/>
    </roles>
    <attributes>
      <attribute name="firstname" value="Alice"/>
      <attribute name="password" value="alice1"/>
    </attributes>
  </user>
</users>
----------------------------------------------------------------

rolse.xml:---->对应role权限设计系统中的角色定义

<?xml version="1.0" encoding="UTF-8"?>
<roles>
  <role description="This role is for IT users of the portal" id="portal.it">
    <resources>
      <resource id="gadget.slashdot"/>
    </resources>
  </role>
  <role description="This role is for normal users of the portal" id="portal.user">
    <resources>
      <resource id="gadget.info"/>
      <resource id="gadget.calc"/>
      <resource id="gadget.news"/>
      <resource id="gadget.joke"/>
      <resource id="gadget.cal"/>
    </resources>
  </role>
  <role description="This role can administer the profilestore" id="profilestore.administrator">
    <resources>
      <resource id="profilestore.AddResource"/>
      <resource id="profilestore.AddResourceToRole"/>
      <resource id="profilestore.AddRole"/>
      <resource id="profilestore.AddRoleToUser"/>
      <resource id="profilestore.AddUser"/>
      <resource id="profilestore.ChangePassword"/>
      <resource id="profilestore.DeleteResource"/>
      <resource id="profilestore.DeleteRole"/>
      <resource id="profilestore.DeleteUser"/>
      <resource id="profilestore.GetUser"/>
      <resource id="profilestore.GetUserProperty"/>
      <resource id="profilestore.GetUsers"/>
      <resource id="profilestore.HasResource"/>
      <resource id="profilestore.HasRole"/>
      <resource id="profilestore.ModifyUser"/>
      <resource id="profilestore.RemoveResourceFromRole"/>
      <resource id="profilestore.RemoveRoleFromUser"/>
      <resource id="profilestore.SetUserProperty"/>
    </resources>
  </role>
</roles>
-----------------------------------------------------------------------

resources.xml:－－－>对应role权限设计中的权限点

 </resource>
  <resource description="The ability to add a resource to a role" id="profilestore.AddResourceToRole">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to add a role" id="profilestore.AddRole">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to add a role to a user" id="profilestore.AddRoleToUser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to add a user" id="profilestore.AddUser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to change a password" id="profilestore.ChangePassword">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to delete a resource" id="profilestore.DeleteResource">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to delete a role" id="profilestore.DeleteRole">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to delete a user" id="profilestore.DeleteUser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to get a user's details" id="profilestore.GetUser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to get a user property" id="profilestore.GetUserProperty">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to get user details" id="profilestore.GetUsers">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to check if a user has  a resource" id="profilestore.HasResource">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to check if a user has a role" id="profilestore.HasRole">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to modify a user's details" id="profilestore.ModifyUser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to remove a resource from a role" id="profilestore.RemoveResourceFromRole">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to remove a role from a user" id="profilestore.RemoveRoleFromUser">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
  <resource description="The ability to set a user property" id="profilestore.SetUserProperty">
    <roles>
      <role id="profilestore.administrator"/>
    </roles>
  </resource>
</resources>
-------------------------------------------------

数据库导出
String path="mysqldump.exe -uuser -ppwd --opt databasename > d:/databack/xx.sql";
java.lang.Runtime.getRuntime().exec("cmd /c "+path);
System.out.println("数据表已导出到文件xx.sql中");

//数据库导入
String path="mysqladmin -uroot -p create databasename";
java.lang.Runtime.getRuntime().exec("cmd /c "+path);
path="mysql databasename ＜ d:/databack/xx.sql";
java.lang.Runtime.getRuntime().exec("cmd /c "+path);
System.out.println("数据表已从文件xx.sql中导入");

内容： 概述 我们的支持示例 策略 1: 每个子类一个表（Persons） 策略 2：每个类层次结构一个表（Rights） 数据库模型的完整性 策略 3: 每个具体类一个表（Estates） 多态 —— 用到极限！ 结束语 参考资料 下载 作者简介 对本文的评价 相关内容： 无需容器的对象关系映射 Using Hibernate to persist your Java objects to IBM DB2 Universal Database Developing Hibernate application for use with WebSphere Application Server IBM developer kits for the Java platform (downloads) 订阅: developerWorks 时事通讯

Xavier Coulon, 电子商务 IT 专家, IBM Business Consulting Services
Christian Brousseau, J2EE 顾问

2005 年 1 月 14 日

Hibernate 是一个对象关系映射和持久性框架，它提供了许多高级特性，从内省到多态和继承映射。但是，把类的层次结构映射到关系数据库模型，可能会比较困难。本文将介绍三个策略，在日常的编程之中您可以用它们把复杂的对象模型容易地映射到关系数据库模型。

概述
Hibernate 是一个纯 Java 的对象关系映射和持久性框架，它允许您用 XML 配置文件把普通 Java 对象映射到关系数据库表。使用 Hibernate 能够节约大量项目开发时间，因为整个 JDBC 层都由这个框架管理。这意味着您的应用程序的数据访问层位于 Hibernate 之上，完全是从底层数据模型中抽象出来的。

比起其他类似的对象关系映射技术（JDO、实体 bean、内部开发等），Hibernate 有许多优势：它是免费的、开源的，已经成熟到良好的程度，并得到广泛应用，而且还有一个非常活跃的社区论坛。

要把 Hibernate 集成到现有的 Java 项目，则需要执行以下步骤：

1. 从 Hibernate 的 Web 站点下载 Hibernate 框架的最新发行版（请参阅 参考资料一节中的链接。）
   
   
2. 把必需的 Hibernate 库（JAR 文件）复制到应用程序的 CLASSPATH。
   
   
3. 创建 XML 配置文件，用它把 Java 对象映射到数据库表。（我们将在本文中描述这个过程。）
   
   
4. 把 XML 配置文件复制到应用程序的 CLASSPATH。

您会注意到，不必修改任何 Java 对象，您就可以支持框架。例如，假设您对 Java 应用程序使用的数据库表做了些修改 —— 例如修改了列名。在修改完表之后，您要做的只是更新对应的 XML 配置文件。 您不需要重新编译任何 Java 代码。

Hibernate 查询语言（HQL）
Hibernate 提供了一个查询语言，叫作 Hibernate 查询语言（HQL），它与 SQL 很相似。如果您喜欢用老式的 SQL 查询，那么 Hibernate 也为您提供了使用它们的机会。但是我们使用的示例只用 HQL。

HQL 用起来相当简单。您会发现所有的关键字都与您熟悉的 SQL 中的关键字类似，例如 SELECT、 FROM 和 WHERE。HQL 与 SQL 的差异在于，您不用针对数据模型（即针对表和列等）直接编写查询，而是应该针对 Java 对象，使用 Java 对象的属性和关系编写查询。

清单 1 演示了一个基本的示例。这个 HQL 代码检索 firstName 为 “John.” 的所有 Individual。

SELECT * FROM eg.hibernate.mapping.dataobject.Individual WHERE firstName = "John"

如果想了解更多有关 HQL 语法的内容，那么您可以参阅 Hibernate 的 Web 站点上有关 HQL 的参考材料（请参阅 参考资料，以获得链接）。

XML 配置文件
功能的核心在于 XML 配置文件。这些文件必须存在于应用程序的 CLASSPATH 中。我们把它们放在示例代码包的 config 目录中（您可以从 参考资料下载）。

我们要研究的第一个文件是 hibernate.cfg.xml。它包含与数据源有关的信息（数据库 URL、模式名称、用户名、口令等），以及对包含映射信息的其他配置文件的引用。

其余的 XML 文件允许您把 Java 类映射到数据库表。稍后我再深入介绍这些文件，但重要的是要清楚它们的文件名要遵守 ClassName.hbm.xml 这个模式。

我们的支持示例
在本文中，我们要研究一个基本示例，演示 Hibernate 如何工作，如何良好地运用三个不同策略，利用 Hibernate 进行对象关系映射。我们的示例是一家保险公司使用的应用程序，公司必须保持客户投保的所有产权的法律记录。我们随本文提供了完整的源代码（请参阅 参考资料）；这个代码提供了基本功能，您可以根据它构建全功能的应用程序，例如 Web 或 Swing 应用程序。

我们的示例采用了这类应用程序的经典用例。用户提供搜索参数，查找各种类型的客户（个人、公司、政府机构等），然后显示与指定参数匹配的所有客户列表 —— 即使这些客户的类型不同。用户可以访问同一列表中的某一特定客户更加详细的视图。

在我们的应用程序中，产权由 Right 类表示。 Right 可以是 Lease 也可以是 Property。 Right 由客户所有。为了表示我们的客户，我们要使用通用类 Person。 Person 即可以是 Individual 也可以是 Corporation。当然，保险公司必须知道这些 Right 被分配给哪个 Estate。您应当同意， Estate 这个术语代表的意义非常泛。所以，我们要用 Land 和 Building 类给我们的开发人员提供更具体的操作对象。

从这个抽象出发，我们可以开发图 1 所示的类模型：

图 1. 完整的类模型

我们的数据库模型是为了介绍将在本文中讨论的三个不同策略而设计的。对于 Right 层次结构来说，我们要使用一个表（ TB_RIGHT），并用 DISCRIMINATOR 列映射到正确的类。对于 Person 结构，我们要使用一个称为 超表（ TB_PERSON）的表，它与另外两个表（ TB_CORPORATION 和 TB_INDIVIDUAL）共享相同的 ID。第三个层次结构（ Estate）使用两个不同的表（ TB_BUILDING 和 TB_LAND），这两个表通过由两个列（ REF_ESTATE_ID 和 REF_ESTATE_TYPE）组合定义的外键连接在一起。

图 2 显示了这个数据模型:

图 2. 完整的数据模型

设置数据库
Hibernate 支持各种各样的 RDBMS，其中任何一种都可以使用我们的示例。但是，本文的示例代码和文本已经针对 HSQLDB（请参阅 参考资料查找链接）进行了调整，这是一个完全用 Java 语言编写的全功能的关系数据库系统。在示例代码包的 sql 目录中，可以找到叫作 datamodel.sql 的文件。这个 SQL 脚本可以创建我们示例中使用的数据模型。

设置 Java 项目
虽然您总能用命令行构建并执行示例代码，但是您可能想在 IDE 中设置项目，以便更好地进行集成。在示例代码包里，您可以找到以下目录：

• config，包含样本的所有 XML 配置文件（映射、Log4J 等）。
  
  
• data，包含 HSQLDB 使用的配置文件。您还可以找到一个叫作 startHSQLDB.bat 的批处理文件，您可以用它启动数据库。
  
  
• src，包含示例的所有源代码。

请确保把必需的 Java 库和 XML 配置文件复制到应用程序的 CLASSPATH。只需要 Hibernate 和 HSQLDB 库，这些代码就可以正确地编译和运行。您可以从 参考资料一节下载这些包。

策略 1: 每个子类一个表（Persons）
在我们第一个策略中，我们要看看如何映射我们的 Person 层次结构。您会注意到，数据模型与我们的类模型非常接近。所以，我们要为层次结构中的每个类采用一个不同的表，但是所有这些表都必须共享相同的主键（我们很快就会详细说明）。Hibernate 在向数据库中插入新记录时，就会使用这个主键。在访问数据库时，它还会利用同一主键执行 JOIN 操作。

现在我们需要把对象层次结构映射到表模型。我们有三个表（ TB_PERSON、 TB_INDIVIDUAL、和 TB_CORPORATION）。前面我们提过，它们都有一个叫作 ID 的列，并将该列作为主键。表之间不一定非要有这样的共享列名称，但是这是一个很好的实践 —— 这样做的话，生成的 SQL 查询更容易阅读。

在清单 2 所示的 XML 映射文件中，您会注意到，在 Person 的映射定义中，声明了两个具体的 <joined-subclass> 类。XML 元素 <id> 映射到顶级表 TB_PERSON 的主键，同时 <key> 元素（来自每个子类）映射到 TB_INDIVIDUAL 的 TB_CORPORATION 表中匹配的主键。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
	"http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping>
  <class name="eg.hibernate.mapping.dataobject.Person" table="TB_PERSON" polymorphism="implicit">
    <id name="id" column="ID">
      <generator class="assigned"/>
    </id>
    <set name="rights" lazy="false">
      <key column="REF_PERSON_ID"/>
      <one-to-many class="eg.hibernate.mapping.dataobject.Right" />
    </set>
    
        <joined-subclass name="eg.hibernate.mapping.dataobject.Individual" table="TB_INDIVIDUAL">
      <key column="id"/>
      <property name="firstName" column="FIRST_NAME" type="java.lang.String" />
      <property name="lastName" column="LAST_NAME" type="java.lang.String" />
    </joined-subclass>
    
        <joined-subclass name="eg.hibernate.mapping.dataobject.Corporation" table="TB_CORPORATION">
      <key column="id"/>
      <property name="name" column="NAME" type="string" />
      <property name="registrationNumber" column="REGISTRATION_NUMBER" type="string" />
    </joined-subclass>
  </class>
</hibernate-mapping>

      

保存 Individual 的一个新实例，形成我们使用 Hibernate 的 Java 代码非常容易，如清单 3 所示：

public Object create(Object object) {
  Session session = null;
  try {
    session = sessionFactory.openSession();
    Transaction tx = session.beginTransaction();
    
        session.save(object);
    session.flush();
    tx.commit();
    ...
}

      

接着，Hibernate 生成两个 SQL INSERT 请求，如清单 4 所示。这两个请求面向的是一个 save()。

insert into TB_PERSON (ID) values (?)
insert into TB_INDIVIDUAL (FIRST_NAME, LAST_NAME, id) values (?, ?, ?)

要想访问数据库中的 Individual，只需在 HQL 查询中指定类名即可，如清单 5 所示。

public Person findIndividual(Integer id) {
  ...
  session.find(
        "select p from " + Individual.class.getName() + " as p where p.id = ?",
    new Object[] { id },
    new Type[] { Hibernate.INTEGER });	
  ...
}

      

Hibernate 会自动执行 SQL 的 JOIN，从两个表中检索所有必要信息，如清单 6 所示：

select individual0_.id as ID, individual0_.FIRST_NAME as FIRST_NAME55_, 
  individual0_.LAST_NAME as LAST_NAME55_ 
  from TB_INDIVIDUAL individual0_ 
  
        inner join TB_PERSON individual0__1_ on individual0_.id=individual0__1_.ID 
  where (individual0_.id=? )

      

查询抽象类 当查询抽象类时，Hibernate 会自动返回一个集合，由匹配的具体异构子类构成。例如，如果我们查询数据库中的每个 Person，Hibernate 会返回一列 Individual 和 Corporation 对象。

但是，当没有指定具体类时，Hibernate 需要执行 SQL 的 JOIN，因为它不知道要查询哪个表。在 HQL 查询返回的检索到的所有表的列中，还会返回一个额外的 dynamic 列。Hibernate 使用 clazz 列来初始化和填充返回的对象。我们把这个类叫作决定因子（determination dynamic），与我们在第二个策略中使用的方法相对。

清单 7 显示了如何指定抽象类的 id 属性查询抽象类 Person，清单 8 显示了 Hibernate 自动生成的 SQL 查询，其中包括表连接：

public Person find(Integer id) {
  ...
  session.find(
        "select p from " + Person.class.getName() + " as p where p.id = ?",
    new Object[] { id },
    new Type[] { Hibernate.INTEGER });	
  ...
}

      

select person0_.ID as ID0_,
        
  casewhen(person0__1_.id is not null, 1,  
  casewhen(person0__2_.id is not null, 2,  
  casewhen(person0_.ID is not null, 0, -1))) as clazz_0_, 
  person0__1_.FIRST_NAME as FIRST_NAME61_0_, 
  person0__1_.LAST_NAME as LAST_NAME61_0_, 
  person0__2_.NAME as NAME62_0_, 
  person0__2_.REGISTRATION_NUMBER as REGISTRA3_62_0_ 
  from TB_PERSON person0_ 
  left outer join TB_INDIVIDUAL person0__1_ on person0_.ID=person0__1_.id 
  left outer join TB_CORPORATION person0__2_ on person0_.ID=person0__2_.id 
  where person0_.ID=?

      

策略 2：每个类层次结构一个表（Rights）
对于我们的 Right 层次结构，我们只使用一个表（ TB_RIGHT）来保存整体类层次结构。您会注意到， TB_RIGHT 表拥有保存 Right 类层次结构的每个属性所需要的所有列。保存的实例值也就会保存在表中，每个没有使用的列则用 NULL 值填充。（因为它到处都是“洞”，所以我们经常把它叫作 瑞士奶酪表）

在图 3 中，您会注意到， TB_RIGHT 表中包含一个额外的列 DISCRIMINATOR。Hibernate 用这个列自动初始化对应的类并相应进行填充。这个类用映射文件中的 XML 元素 <discriminator> 进行映射。

图 3. TB_RIGHT 表的内容

简明性技巧 在每个大型项目中，您都会面临包含多级抽象类的复杂的类层次结构。幸运的是，您不必指定抽象类的 discriminator-value，只需为 Hibernate 实际要使用的具体类指定这个值即可。

正如清单 2 所示的 Person 映射文件，在清单 9 中，我们映射了抽象类（ Right）及其所有属性。要映射两个具体类（ Lease 和 Property），就要使用 <subclass> XML 标签。这个标签非常简单；它要求 name 属性，仅仅是因为 class 标签要求 discriminator-value 属性。Hibernate 将用后一个属性标识它要处理的类。

从 图 1 的类图中您会注意到， discriminator 不是任何 Java 类都有的属性。实际上，它甚至没有映射。它仅仅是 Hibernate 和数据库之间共享的一个技术性的列。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC 
  "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
  "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">
<hibernate-mapping>
  <class name="eg.hibernate.mapping.dataobject.Right" table="TB_RIGHT" polymorphism="implicit">
    <id name="id" column="ID">
      <generator class="assigned"/>
    </id>
    
        <discriminator>
      <column name="DISCRIMINATOR"/>
    </discriminator>
    <property name="date" column="DATE" type="java.sql.Date" />
    <many-to-one name="person" class="eg.hibernate.mapping.dataobject.Person" column="REF_PERSON_ID"/>
    <any name="estate"
         meta-type="string"
         id-type="java.lang.Integer">
      <meta-value value="LND" class="eg.hibernate.mapping.dataobject.Land"/>
      <meta-value value="BLD" class="eg.hibernate.mapping.dataobject.Building"/>
      <column name="REF_ESTATE_TYPE"/>
      <column name="REF_ESTATE_ID"/>          
    </any>
    
    
        <subclass name="eg.hibernate.mapping.dataobject.Property" discriminator-value="PRO"/>
    
    <subclass name="eg.hibernate.mapping.dataobject.Lease" discriminator-value="LEA">
      <property name="duration" column="DURATION" type="java.lang.Integer" />
     
        </subclass>
  </class>
</hibernate-mapping>

      

在清单 9 的映射文件中，您会注意到 Right 和 Person 层次结构之间的“多对一”关系，它（实质上）与 Person 层次结构（一对多）的关系正好相反。还请注意 Right 和 Estate 层次结构之间的关系；稍后我们将在本文中介绍这层关系。

使用第一个策略时，Hibernate 在访问数据库时生成了非常有效的 SQL 语句。当我们查询具体类时，如清单 10 所示，会在 discriminator 的 Hibernate 过滤器上自动取值 —— 这是件好事，因为这意味着 Hibernate 只读取与指定类对应的列。

select property0_.ID as ID, property0_.DATE as DATE, 
	property0_.REF_PERSON_ID as REF_PERS4_, property0_.REF_ESTATE_TYPE as REF_ESTA5_, 
	property0_.REF_ESTATE_ID as REF_ESTA6_ 
	from TB_RIGHT property0_ where property0_.DISCRIMINATOR='PRO'

当我们查询抽象类时，事情变得有些复杂。因为 Hibernate 不知道您要查询哪个特定的类，所以必须读取每个列（包括 discriminator 类），然后才能决定要初始化哪个类，最后再填充它。接下来，discriminator 充当的角色与第一个策略中 clazz 列充当的角色相同。但是这个方法显然更死板，因为类名直接派生自 discriminator 的值。

select right0_.ID as ID, 
	right0_.DISCRIMINATOR as DISCRIMI2_, 
	right0_.DATE as DATE, right0_.REF_PERSON_ID as REF_PERS4_, 
	right0_.REF_ESTATE_TYPE as REF_ESTA5_, right0_.REF_ESTATE_ID as REF_ESTA6_, 
	right0_.DURATION as DURATION from TB_RIGHT right0_

策略的不兼容 按照 Hibernate 映射的 DTD 定义，本文中描述的前两个策略是相互排斥的，这意味着它们无法组合在一起，映射同一个层次结构。

数据库模型的完整性
关于第二个策略，有一个需要重点考虑的地方：为了让它工作，必须把所有非共享列设置为 NULLABLE。因为开发人员通常会依赖数据库的约束，所以生成的表可能非常难以处理。（毕竟，把有持续时间的 Lease 设置为 NULL 没多大意义！）

解决方案之一是用 数据库级检测约束。您可以根据 DISCRIMINATOR 的值，定义一套要实施的规则，如清单 12 所示。当然，数据库引擎必须支持这些特性。而且，由于必须同时为全部具体类用一个有效表达式表示这些约束，所以当层次结构发展的时候，维护会很困难。

alter table TB_RIGHT 
	add constraint CHK_RIGHT check(	
		(discriminant ='DPP' and date is null and duration is null)
	or	(discriminant ='DLM' and date is not null and duration is not null));

策略 3: 每个具体类一个表（Estates）
我们的第三个，也是最后一个策略可能是三个策略当中最有想象力的：每个具体类一个表，抽象超类 Estate 没有表。我们依靠 Hibernate 提供对 多态（polymorphism）的支持。在清单 3 所示的 XML 映射文件中，您会注意到，其中只映射了两个具体类（ Building 和 Land）：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC 
  "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
  "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping>
  <class name="eg.hibernate.mapping.dataobject.Land" table="TB_LAND" polymorphism="implicit">
    <id name="id" column="ID">
      <generator class="assigned"/>
    </id>
    <property name="description" column="DESCRIPTION" type="java.lang.String" />
    <property name="squareFeet" column="SQUARE_FEET" type="java.lang.Double"/>
  </class>

  <class name="eg.hibernate.mapping.dataobject.Building" table="TB_BUILDING" polymorphism="implicit">
    <id name="id" column="ID">
      <generator class="assigned"/>
    </id>
    <property name="description" column="DESCRIPTION" type="java.lang.String" />
    <property name="address" column="ADDRESS" type="java.lang.String"/>
  </class>
</hibernate-mapping>

在表间共享 ID 值 要点在于，在同一类层次结构中映射的两个表之间，不必共享相同的 ID 值。如果您进行映射，那么 Hibernate 会为同一 ID 返回多个不同的对象。这可能会使 Hibernate 弄混 —— 您也会弄混。

当您查看清单 13 中的映射文件时，您的第一个反应可能是说：“呵！这个映射与我每天使用的没什么不同啊！这里没什么重要的东西！”而且您这么想应当是对的。实际上，第三个策略只需要一个条件：需要把 polymorphism 属性设置为 implicit。

即使在映射文件中找不到 Estate 类，它仍然存在于类层次结构之中。而且，因为两个映射的类（ Building 和 Land）是从 Estate 中继承而来，所以我们可以在 HQL 查询中使用这个抽象超类，如清单 14 所示。Hibernate 会用 内省（introspection） 找到扩展这个抽象类的类，以便依次为每个子类执行对应的 SQL 查询。

public Estate find(Integer id) {
  ...
  List objects =
    session.find(
      "select e from " + Estate.class.getName() + " as e where e.id = ?",
        new Object[] { id },
        new Type[] { Hibernate.INTEGER });
  ...
}

为了找到与指定 ID 匹配的 Estate，Hibernate 必须把清单 15 中的两个查询提交给数据库。

select land0_.ID as ID, land0_.DESCRIPTION as DESCRIPT2_, land0_.SQUARE_FEET as SQUARE_F3_ 
from TB_LAND land0_ where (land0_.ID=? )

select building0_.ID as ID, building0_.DESCRIPTION as DESCRIPT2_, building0_.ADDRESS as ADDRESS 
from TB_BUILDING building0_ where (building0_.ID=? )

正如我们在第二个策略中看到的，在 Right 和 Estate 类之间存在着 多对一 关系。在一般的表述中，这两个表的关系可以这么表述：“一个 Estate 可以指向 许多 Right。但是每个 Right 只能指向 一个 Estate。”但是从我们数据模型的角度来看，我们没有一个惟一的表可以用来创建我们的外键约束，就像 TB_RIGHT 和 TB_PERSON 之间那样。这使得我们几乎不可能创建外键。幸运的是，Hibernate 为我们提供了一个非常强大的 XML 映射元素 —— <any> 标签，它的用法如清单 16 所示。

<any name="estate"
	meta-type="string"
	id-type="java.lang.Integer">
  <meta-value value="LND" class="eg.hibernate.mapping.dataobject.Land"/>
  <meta-value value="BLD" class="eg.hibernate.mapping.dataobject.Building"/>
  <column name="REF_ESTATE_TYPE"/>
  <column name="REF_ESTATE_ID"/>          
</any>

禁止多态 对于多态支持被禁止的类（ <class...polymorphism="explicit"...>），如果针对它们的超类进行查询，会把它们排除在外。

我们进一步查看我们的新映射。我们的 虚拟外键 基于 TB_RIGHT 表的两个列。第一个列（ REF_ESTATE_TYPE）包含 discriminator 字符串，用这个字符串映射对应的类名。第二个（ REF_ESTATE_ID）是另外一个表的主键的列名。使用默认设置时，Hibernate 会在第一个列中保存映射的类名，这么做可能会非常消耗空间、没有效率（特别是在代码重构修改类名的时候）。谢天谢地，Hibernate 还提供了一个用 <meta-value> XML 元素把类名映射到字符串约束的方法。这些约束的作用与在第二个策略中讨论的 discriminator 的作用相同。再次声明，这些特性只包含 Hibernate 和数据库，所以不会改变类的层次结构。

数据库模型的完整性
虽然标准 SQL 不允许对多个表同时针对指定列进行参考约束，但是仍有可能添加触发器，根据读取的 discriminator 值，触发器会检测目录中是否有数据。但是，这样的 完整性实施 方法可能非常难以维护，也有可能降低数据的整体性能。

多态 —— 用到极限！
在使用 Hibernate 内置的多态时需要记住一件事：如果您一不小心，把所有的类都用 polymorphism 属性设置为 implicit，那么您检索到的信息可能要比您想要的多得多。清单 17 显示了一种使用两个词的 HQL 查询来检索 整个数据库 的方法。

public List all() {
  ...
  List objects = session.find("
        from Object");
  ...
}

      

该查询的功能非常强大，您觉得呢？当然，我们之中没有多少人需要只用一个 HQL 查询检索整个数据库。这个（没有实际意义）的示例的目的就是为了显示隐式多态的能力。您可以利用这个能力避免把无用的、耗费资源的 SQL 查询发送到数据库。

结束语
在本文中，我们试图向您提供一个相当简单的实现示例，演示 Hibernate 提供的三个映射策略。回头来看，每个策略都有自己的优势与不足：

• 对于第一个策略（每个子类一个表），Hibernate 每次初始化和填充对象时，会读取多个表。如果您的索引定义得很好，而且层次结构不是太深，那么这个操作可以产生良好的结果。但是，如果不是这种情况，那么您可能会遇到各种性能问题。
  
  
• 对于第二个策略（每个类层次结构一个表），您必须用 检测约束 定义您自己的完整性。但随着列的数量与时俱增，这个策略可能会变得难以维护。另一方面，您可能选择根本不用这样的约束，而依靠应用程序的代码来管理自己的数据完整性。
  
  
• 第三个策略（每个具体类一个表）有一些映射限制，而底层数据模型不能使用参照完整性，这意味着您不能发挥关系数据库引擎的所有潜力。但是，从好的方面说，该策略很常容易与另两个策略组合在一起。

不管您选择哪种策略，都要记住，在整个过程当中，无需修改 Java 类，这意味着业务对象与持续性框架之间一点联系都没有。正是这样高水平的灵活性使 Hibernate 在对象关系 Java 项目中如此流行。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 请单击本文顶部或底部的 Code 图标下载本文中使用的源代码示例。
  
  
• Hibernate site 提供了您需要的与这个强大的对象持久性框架有关的所有信息。可以从这个站点下载运行示例应用程序所需的 Hibernate 文件。
  
  
• HSQLDB 数据库是一个开源的轻量级数据库，完全用 Java 语言编写。可以从这个站点下载 HSQLDB，并把它用作示例应用程序的数据库。
  
  
• 请参阅 Hibernate 撰写的 HQL reference，来获得 Hibernate 查询语言的完整文档。
  
  
• “ Using Hibernate to persist your Java objects to IBM DB2 Universal Database”，作者是 Javid Jamae 和 Kulvir Singh Bhogal（developerWorks，2003 年 6 月），该书提供了用 Hibernate 将类映射到数据库表的良好指导。
  
  
• “ 无需容器的对象关系映射 ”，作者是 Richard Hightower，（developerWorks，2004 年 4 月），它对使用 Hibernate 和 Spring 框架开发事务性持久性层进行了介绍。
  
  
• “ Developing Hibernate 应用程序s for use with WebSphere Application Server”，作者 Sunil Patil（ IBM WebSphere Developer Technical Journal， 2004 年 9 月），提供了创建 Hibernate 应用程序时使用 Websphere Application Server 连接和事务管理的详细指导。
  
  
• “ Hibernate your data”，作者是 Davor Cengija（ONJava.com，2004 年 1 月），它提供了 Hibernate API 的所有基础知识，描述了如何利用 Hibernate API 的映射文件。
  
  
• Hibernate in Action ，作者是 Christian Bauer 和 Gavin King（Independent Pub Group，2004 年），这是一份关于对象关系映射的理论与实践指南。由 Hibernate 小组编写。
  
  
• Hibernate: A Developer's Notebook ，作者是 James Elliot（O'Reilly，2004 年），这是另一份 Hibernate 的精彩指南。
  
  
• 在 developerWorks Java 技术专区 中，可以找到数百篇有关 Java 各个方面的技术文章。
  
  
• 请访问 Developer Bookstore，以获得技术书籍的完整清单，其中包括数百本 Java 相关主题的书籍。
  

	Name				Size				Download method
	j-hibernate-source.zip								FTP

关于下载方法的信息

作者简介 Xavier Coulon 六年前以 IT 专家的身份加入 IBM 的法国分部，并开始从事各类平台上的 ERP 咨询工作。最近两年，他一直在处理一个大型 J2EE 项目，这个项目包含诸如 Struts 和 Hibernate 之类的开源框架。您可以通过 xavier.coulon@fr.ibm.com 与 Xavier 联系。

Christian Brousseau 是一个了不起的加拿大人，他一直在开发软件，有十多年的经验。最初他做了大量 Windows 开发（C++、Visual Basic、MFC、ActiveX），后来，从 Java 语言的 1.0 版本起，他开始转移到 Java 项目上。做 J2EE 顾问时积累的专业知识为他提供了一个去法国的好机会，在法国，他协助设计、开发、部署了一些重要的企业级 J2EE 项目。可以通过 cbrous@fr.ibm.com 与 Christian 联系。

• 第1部分 构建易于单元测试的对象结构。                   <- now
• 第2部分 集成PicoContainer来更完美的消除对象依赖。

实现和接口分离，使用和组装分离是一个基本的对象设计原则，简单的工厂方法(gof)、服务定位器模式(j2ee核心模式)已经被广泛使用,近来由于测试驱动方法的深入人心，有洁癖的程序员们又重新理解了ioc(Inversion of Control)，并把它们变成实现，代表性的实现有PicoContainer,Spring，而Martin Fowler也趁机总结出了一个新的模式：Dependency Injection ，让我们别停留在理论与争论了，看看怎样用它来实际的简化我们的程序才是正解，用过之后再吵个翻天也不迟。本文将通过一个数据库访问层和web层的集成来应用picoContainer.让我们这就来看它的威力吧。

本文假设你具有junit单元测试/web框架,使用经验,最好了解webwork 1机理,不过他简单的你甚至可以现在才了解。

先看看文中所用的东东：

• webwork 1 :  一个非常简单的web框架，核心接口是 Action.execute(),我们将实现之来处理每一次web层的action(也就是一次post) 。
• dao模式(j2ee核心模式) :他将封装数据库访问的所有细节。

让我们来看看通常我们实现一个简单的用户登陆过程所要做的所有事情：

从上图可知LoginAction是我们程序的顶层类,它依赖UserDao来完成登陆业务逻辑，ok,这就是一个典型的web应用，一次请求发送到web server，然后由webwork框架接管，他按照一个配置文件把相应的登陆请求对应到LoginAction类上，然后用其缺省的构造器实例化LoginAction,然后把post上来的表单值或url参数值按名称填充到LoginAction（即：name,password）,然后调用命令模式的接口Action.execute()完成调用，让我们来看一下实际代码：

public interface UserDao {
    public User load(String username);
}                          

import webwork.action.ActionSupport;
import ftsmen.dao.UserDao;
import ftsmen.entity.User;

public class LoginAction extends ActionSupport {
    private String username;
    private String password;
    private UserDao userDao ;

    public LoginAction() {
	//依赖对象在这里初始化
        userDao = DaoFactory.createUserDao();
    }

    //为了程序的简单，假设用户总是已经注册过的
    public String execute() {
	User u = userDao.load(getUsername());
	if (!u.verifyPassword(getPassword())) {
	    //密码错误;
	    return ERROR;
	}
	//验证通过......可以把用户信息放在session中
	return SUCCESS;
    }

    public String getUsername() {
	return username;
    }
    public void setUsername(String string) {
	username = string;
    }
    public String getPassword() {
        return password;
    }
    public void setPassword(String string) {
	password = string;
    }
}                

对象知识告诉我们要让接口和实现分离，于是我们就用工厂方法隐藏了UserDao的实现和初始化细节。我们将如何测试LoginAction而不依赖UserDao的数据库实现呢？我们知道单元测试的一个常用方法是：用mock object替换待测试类的依赖对象,具体使用可以参考MockObjects、JMock.

我们这里用一个子类来充当mock，但究竟怎样把这个mock object替换LoginAction中的那个userDao呢？？？

目前常用的3种方法都可以做到,参考Dependency Injection：

1.服务定位器(Service Locator):

我们可以把DaoFactory简单的改造为服务定位器：

public class DaoFactory{	
    private static ThreadLocal instance = new  ThreadLocal();
    private UserDao userDao;
    public DaoFactory(UserDao userDao) {
	this.userDao =userDao ;
    }
    private DaoFactory() {}
    public static void load(DaoFactory locator) {
       instance.set(locator);
    }
    public static UserDao createUserDao() {
	return ((DaoFactory)instance.get()).userDao;
    }
}
                

这样就可以不改变原来的LoginAction代码，并可以把mock UserDao插入到待测类LoginAction中：

public class LoginActionServiceLocatorTest extends TestCase {
    public void testLogin() throws Exception {
         DaoFactory.load(new DaoFactory(new UserDao() {
    	    public User load(String username) {
	        User u = new User(username);
		u.setPassword("chen");
		return u;
	    }
	}));
        
	action.setUsername("chen56");
	action.setPassword("chen");
	assertEquals("正确登陆", Action.SUCCESS, action.execute());
    }
}
                

当然最后还应该把DaoFactory重构rename为更贴切的名称.

2.setter 注射(Setter Injection):
    我们在LoginAction中加入一个新的方法：

public void setUserDao(UserDao userDao){
    this.userDao=userDao;
}               
                

public class LoginActionSetterInjectionTest extends TestCase {
    public void testLogin() throws Exception {
        LoginAction  action = new LoginAction();
        action.setUserDao(new UserDao() {
	   public User load(String username) {
	       User u = new User(username);
	       u.setPassword("chen");
	       return u;
	   }
        });

        action.setUsername("chen56");
        action.setPassword("chen");
        assertEquals("正确登陆", Action.SUCCESS, action.execute());
    }
}
                

    public LoginAction(UserDao userDao) {
        this.userDao = userDao;
    }
                          

public class LoginActionConstructorInjectionTest extends TestCase {
    public void testLogin() throws Exception {
        LoginAction  action = new LoginAction(new UserDao() {
	   public User load(String username) {
	       User u = new User(username);
	       u.setPassword("chen");
	       return u;
	   }
        });

        action.setUsername("chen56");
        action.setPassword("chen");
        assertEquals("正确登陆", Action.SUCCESS, action.execute());
    }
}
                

以上实现中:Service Locator方法对源程序基本没有修改，但实际组装UserDao的工作却从原来的DaoFactory中分离了出来，通常情况下，我们会在filter或一个所有Action的基类中用模版方法实现他的组装，比如实际上可能会组装hibernate的一个Session到UserDao中。

后2个实现其实在程序中保留了一处专为测试所用的依赖对象入口，在实际使用中，构造器注射更舒心一些。由于我们知道webwork是用缺省构造器来初始化类的，而我们测试则用带UserDao参数的构造器，所以这是一个单选题，很少会产生误解，并且也更简洁些，类的状态也不会在运行期变化。

注：事实上遵守Kent beck的教诲，LoginActionTest是先于LoginAction开发出来的。  

ok,前面的方法可以使单元测试更容易些，下面来看看更酷的：集成pico让程序更简洁。

picoContainer为何物？大家可以google上找一下，连接很多。

我们只说明一下它在我们的程序中的作用并用下面的代码来展现它的可爱之处：

集成pico之后的webwork与上一部分的图示只有一点点不同，就是在实例化Action时，它会查找注册到picoContainer本身的组件，也就是注册到pico中的UserDao,并根据匹配的构造器初始化Action类，即执行new LoginAction(userDao)然后调用Action.execute().就这一点点的不同，让我们看看对我们的构造器注射方式的代码产生了些啥变化。

LoginAction 类：去掉了缺省的构造器。

import webwork.action.ActionSupport; import ftsmen.dao.UserDao; import ftsmen.entity.User; public class LoginAction extends ActionSupport { private String username; private String password; private UserDao userDao ; public LoginAction(UserDao userDao) { //依赖对象在外部初始化 this.userDao = userDao; } //为了程序的简单，假设用户总是已经注册过的 public String execute() { User u = userDao.load(getUsername()); if (!u.verifyPassword(getPassword())) { //密码错误; return ERROR; } //验证通过......可以把用户信息放在session中 return SUCCESS; } public String getUsername() { return username; } public void setUsername(String string) { username = string; } public String getPassword() { return password; } public void setPassword(String string) { password = string; } }

测试类：没有变化

public class LoginActionConstructorInjectionTest extends TestCase { public void testLogin() throws Exception { LoginAction action = new LoginAction(new UserDao() { public User load(String username) { User u = new User(username); u.setPassword("chen"); return u; } }); action.setUsername("chen56"); action.setPassword("chen"); assertEquals("正确登陆", Action.SUCCESS, action.execute()); } }

UserDao总有被初始化的时候，ok,现在我们把初始化工作集中在一个WebContainerComposer中，并且在web.xml中用context-param描述它，这样，pico就可以根据pico容器中相应的UserDao组件初始化UserAction类了.

package ftsmen.web.action; import org.picocontainer.MutablePicoContainer; import org.picoextras.integrationkit.ContainerComposer; import ftsmen.dao.UserDao; import ftsmen.dao.HibernateUserDao; import ftsmen.db.Database; public class WebContainerComposer implements ContainerComposer { String _nameStr; public void composeContainer(MutablePicoContainer container, Object name) { _nameStr = name.toString().toLowerCase(); if (isScope("application")) { //可以把scope为application的组件注册到这里 } else if (isScope("session")) { //可以把scope为session的组件注册到这里 } else if (isScope("request")) { //可以把scope为request的组件注册到这里 //真实程序中Hibernate的Dao实现用Session来初始化 container.registerComponentInstance( new HibernateUserDao(Database.currentSession())); /*jdbc实现可能象这样 container.registerComponentInstance( new JdbcUserDao(Database.connection())); */ } } private boolean isScope(String scope) { return _nameStr.indexOf(scope) != -1; } }

可以看到，集成pico后的源代码更洁净了，并且Factory的依赖也消除了。

还有什么比清洁溜溜的代码更说明问题呢？

具体集成pico和webwork的方法可以参照
http://www.opensymphony.com/webwork/cookbook/PicoContainer_Integration.html

但其中的WebContainerAssembler类的实现现在已经有所变化，在2004年2月2日左右的实现已经变为我给出的写法。

以上实现并不表明pico只支持构造器注射，实际上目前2个主要的框架spring和pico都支持构造器和setter注射。

总结：用pico或spring这样的东东可以迅速的提高程序依赖方面的质量，你不想试一下吗？

资源：

• 这里给出一个已经集成过pico-1.0beta5的webwork1.4的例子下载
  
• Inversion of Control Containers and the Dependency Injection pattern
  Martin Fowler文章 ，听说熊节的译文将登在程序员第3期上
  
• Oh no, we're testing the Mock! 
  一篇很好的关于用Mock对象测试的文章，还好，我不是其中的反例

关于作者：

陈鹏，狂热的程序员 email chen56@msn.com  

public class SomeBusinessClass {
//Core data members //此class的核心資料
//Other data members: Log stream, data-consistency //其他Class的資料
public void performSomeOperation(OperationInformation) {
//Ensure authentication//進行身分驗證
//Lock the object to ensure data-consistency in case other threads access it
//Ensure the cache is up to date
//Log the start of operation //記錄日誌
// ==== Perform the core operation ==== //處理核心作業
//Log the completion of operation //記錄日誌
//Unlock the object
}
//More operations similar to above
public void save(PersitanceStorage ps) {
}
public void load(PersitanceStorage ps) {
}
}

即使是這樣簡單的類別，還是有一些地方值得我們注意：
1. “Other data members”部分所宣告的物件，基本上並不屬於這個類別主要的關心事項（concern），雖然還是必須要用到它。
2. “performSomeOperation()”這個method除了處理自己的核心作業外，還必須負責呼叫身分驗證、鎖定欲處理的資料、記錄日誌等額外的工作，這些工作似乎與他的責任不太相關，但又找不出必須由誰來做這些事情。
3. 如果save()及load()兩個method也是這個類別的核心程式的話，我們很容易就忽略了這層關係，使注意力集中到別的地方了。

　　 基於這一類的問題，我們可以看出，OOP雖然可以很適當的表現出系統的模組化，但當遇到需要跨越模組（或類別）的應用時（這些模組（或類別）可能與主要作業邏輯是沒有什麼關係的，如身分驗證、日誌記錄等），OOP就無法以較自然的方式來表現或處理。這種被稱為橫切關係（crosscutting）的行為，常會造成軟體設計或實作時不夠簡潔，不易了解，甚至會造成日後維護上的困難。雖然我們可以利用extend的方式來加以萃取，或引入design pattern來減少這種情形，但由於使用的地方不同，就必須引入新的設計，不但造成設計的困難度增加，也造成日後他人學習、維護上的障礙；圖一 是另一個例子，紅色字是所謂的橫切關係的部分，程式的錯綜複雜可想而知。為了解決上述橫切關係所造成的困擾，AOP的概念便被提出。

圖 一

AOP（Aspect Oriented Programming）
　　AOP主要的概念是萃取互相獨立的橫切關係事項而加以模組化，使之可以有效的集中、管理，而不會分散在程式碼的各個地方。AOP能有這樣的能力，主要是其特殊的實作架構，實現AOP的運作原理，首先必須先告訴aspect的實作者（例如稍後會提到的AspectJ），程式的哪些特殊點為橫切關係（我們可以稱其為連接點（join point），一般如method被呼叫的點），將被攔截並加入aspect的規則，這些aspect規則可能是額外的動作或取代原來程式功能等，接著透過aspect實作者特有的compiler，將相對應的aspect程式碼加入之前設定的連接點中（一般稱為aspect weaver，參考 圖二），然後再加以執行，便可以使原來的程式不用在程式碼中呼叫這些特殊橫切關係，而仍能得到所要的結果（以log的例子來說，我們不用再呼叫log，但程式執行的結果卻會幫我們產生log）。

圖 二

所以加入了AOP的概念後，我們可以看到 圖 1 的程式可以有這樣的改變（如：圖 三）

圖三

　　由於AOP在使用上有這種特殊性，當我們在使用它的時候，一般會搭配其他主要的程式設計的方法來共同建構一個系統，例如，以OOP來當成它的主要底層結構，建構系統主要的核心作業，然後再用AOP填補OOP不足的特殊橫切關係。

　　 有了aspect的理論架構，接著我們來看看怎麼將它實際的應用在我們的另一個主題“單元測試（Unit Test）”上；我們將使用Xerox的PARC實驗室發展出來的AspectJ來作為接下來實作的語言。AspectJ（Java base AOP implementation language）是實作AOP的語言之一，它擴充自Java語言，並與Java語言互相搭配，一同實現aspect的機制。

傳統的單元測試（Unit Test）方式
　　當系統開發時，常常需要對某一個個別的物件進行單元測試，以求得物件的正確性；圖 4 是一個簡單的單元測試模型。

當我們針對某個物件進行單元測試時，如果這個被測的物件又呼叫到別的物件（如 圖 四 中LoginView物件用到AccessController物件時），此時為了使這個被呼叫的物件不會影響到我們的被測物件，我們常常就會用一個假的物件來取代這個額外物件，這個假物件就是單元測試中常常被提到的Mock Object（如 圖 5 的例子）。使用Mock Object的好處是我們可以保留唯一一個真實的被測物，使其他額外的物件都是模擬的，如此便可以很容易的餵入測試資料或模擬其他如資料庫或網路連線等狀態，來達到測試的需求。

圖四

雖然Mock Object可以解決這些問題，但隨著系統的發展及變更，Mock Object會跟著越來越多，反而造成Mock Object維護不易，單元測試的成本愈來愈高；於是，我們必須找出一種方法，既可以不用維護Mock Object的程式碼，又可以達到Mock Object的功能與好處。

　　由於AOP的概念之一是攔截特殊method的呼叫，並取代其內容，這樣的行為與Mock Object的功能非常類似，再加上部分單元測試的研究文獻，也提到這樣的做法，於是我們認為使用AspectJ，應該可以解決Mock Object所產生的問題。

圖五

使用Aspect的概念來進行單元測試利用AOP的概念，整個測試架構可以修改如 圖 六。

圖六

詳細的動作過程，說明如下：
1. 首先設定攔截連接點的條件（利用AspectJ的程式來實作，如 圖 6 MethodInterceptor部分），我們假設所有被測物件及其相關的所有物件的method呼叫都是可攔截的連接點，而Unit Test class及AspectBasedTest class則不在攔截的範圍，因為test case內的程式碼，並沒有被攔截取代的必要。
2. 接著提供一個可以設定哪些method將被取代的設定機制（如 圖六 的AspectBasedTest class）；當程式執行時，很多相關的method呼叫都會被攔截，我們必須可以設定哪一些method要用我們的設定值來取代其執行結果，哪一些method被攔截後不會被取代，而是進行正常的執行動作。這樣，當測試程式執行時，我們才能掌握所有的測試環境。
3. 完成了上述的機制後，我們看一下整個動作的過程；當測試程式開始執行時，會先設定要被取代的method call（即連接點），取代後又會傳回哪一些回傳值等，接著便開始執行測試的程式碼，當它呼叫設定的method call時，AspectJ的程式便會去判斷這些method call是否被指定要被取代，如果不需要被取代，則程式便會執行原來的method，如果這些method call已經被設定必須被取代，則AspectJ便會傳回被指定的回傳值，使被測物件能在執行時取到事先設定的測試資料，最後，測試完成並顯示測試的結果。
4. 以下是AspectJ攔截點與設定模擬method機制的程式碼及說明：
/** 此class讓使用者可以設定哪一些method call要在攔截時被取代以及取代後要傳回什麼要的值，這就好像模擬一個Mock Object的method call，只是我們不需真的去寫Mock Object
*/
public class ComponentTestCase extends TestCase
{
public ComponentTestCase(String name)
{
super(name);
}
//設定哪些method call要被當成mock的method call以及當它被呼叫時，要傳回什麼值。這裡我們主要是使用一個Hashtable來儲存使用者設定的回傳值，當程式執行時呼叫到這個method，取代的機制就會啟動，於是就會到Hashtable內去取得相對應的回傳值；如果找不到相對應的值，就傳回null，代表該method並未被設定要被取代
public static void setMock(String className, String methodName, Object returnValue)
{
testData.put(makeKey(className, methodName), returnValue);
}
public static void setMock(String className, String methodName)
{
setMock(className, methodName, new Object());
}
//取回之前設定的回傳值
public static Object getMockReturnValue(String className, String methodName)
{
return testData.get(makeKey(className, methodName));
}
//驗證設定的mock method call是否如預期的被測試程式使用到
public void assertCalled(String className, String methodName)
{
if ( ! isCalled(className, methodName) )
fail("The method '" + methodName + "' in class '" +
className + "' was expected to be called but it wasn't");
}
//驗證使用mock method call的參數是否如預期正確輸入的相關程式
public Object getArgument(String className, String methodName, String argumentName)
{
Object argument = null;
Hashtable arguments = (Hashtable)callsMade.get(makeKey(className, methodName));
if (arguments != null)
argument = arguments.get(argumentName);
return argument;
}
//驗證設定的mock method call是否如預期的被測試程式使用到的相關程式
public static void indicateCalled(String className, String methodName, Hashtable arguments)
{
callsMade.put(makeKey(className, methodName), arguments);
}
//驗證設定的mock method call是否如預期的被測試程式使用到的相關程式
public static boolean isCalled(String className, String methodName)
{
return callsMade.get(makeKey(className, methodName)) != null;
}
//驗證使用mock method call的參數是否如預期正確輸入
public void assertArgumentPassed(String className, String methodName,
String argumentName, Object argumentValue)
{
Object argument = getArgument(className, methodName, argumentName);
if (argument == null || !argument.equals(argumentValue))
fail("The argument '" + argumentName + "' of method '" +
methodName + "' in class '" +
className + " ' should have the value '" +
argumentValue + "' but it was '" +
argument + "'!");
}
//組合Hashtable所使用的Key的程式
private static String makeKey(String className, String methodName)
{
return className + "." + methodName;
}
private static Hashtable testData = new Hashtable();
private static Hashtable callsMade = new Hashtable(); }

/**此程式是AspectJ攔截點設定程式，主要是設定哪些method call會被此程式加以取代，也就是說，被設定了攔截的method call，在別人呼叫時，會先跑到這個程式來執行，再依程式的邏輯決定要執行真正的method或用其他值取代
*/
aspect AspectBasedMethodInterceptor
{
pointcut allCalls():execution(* *.*(..)) && !within(ajmock.*); //設定哪些method call是攔截點
Object around() : allCalls() //攔截點攔截後要做的事（around()在AspectJ中是取代攔截的call）
{
String className = thisJoinPoint.getSignature().getDeclaringType().getName();
Object receiver = thisJoinPoint.getThis();
if (receiver != null)
className = receiver.getClass().getName();
String methodName = thisJoinPoint.getSignature().getName();
//嘗試去取得mock method call的回傳設定值
Object returnValue = ajmock.ComponentTestCase.getMockReturnValue(className, methodName);
//回傳值如果不是空的，表示此method call是使用者設定的mock method call必須用使用者設定的回傳值來取代
if (returnValue != null)
{
Hashtable arguments = (Hashtable)getArguments(thisJoinPoint);
//呼叫此method主要是為之後的method call驗證之用
ComponentTestCase.indicateCalled(className, methodName, arguments);
return returnValue;
} else {
//如果回傳值是空的，表示此method call不是使用者設定的mock method call，必須執行原來的method，而不被取代
return proceed();
}
}
//取得method call的參數值以便做事後的驗證（驗證是否與使用者之前設定的參數值相同）
private Hashtable getArguments(JoinPoint jp)
{
Hashtable arguments = new Hashtable();
Object[] argumentValues = jp.getArgs();
String[] argumentNames =
((CodeSignature)jp.getSignature()).getParameterNames();
for (int i = 0; i < argumentValues.length; i++)
{
if (argumentValues[i] != null)
arguments.put(argumentNames[i], argumentValues[i]);
}
return arguments;
}
}
5. 測試程式便可以這樣寫
public class TestLoginView extends ComponentTestCase { //繼承設定模擬method機制的class

public TestLoginView(String s) {
super(s);
}
protected void setUp() {
}
public void testValidateValidUser() {
LoginView view = new LoginView();
Integer mockResult = new Integer(AccessController.USER_INVALID);
//設定ajusage.AccessController的login method要被取代，取代值是mockResult
setMock("ajusage.AccessController","login", mockResult);
/呼叫被測試method
view.validate();
//驗證測試結果
assertEquals("login successful", view.getStatus());
}

如此便達到我們的需求，不但可以使用Mock Object的好處，又可以不須維護額外的程式碼。

總結
　　麻省理工學院在2001一月份出刊的Technology Review雜誌中，特別選出可改變未來世界的10大創新科技（http://www.technologyreview.com/articles /tr10_toc0101.asp），在其中一項”解開糾結的程式碼”（Untangling Code）中提到，AOP的出現能有效幫助軟體發展者開發出容易解讀的程式碼，降低軟體開發的複雜度，所以將其列為可以改變未來世紀的科技之一。對AOP所擁有的功能來說，Unit Test祇是其中一小部份的應用，它對程式的模組化或重整等，也都可發揮不小的益處，端看我們對它的活用程度而定。而這篇文章，也不過是一個開端而已。

1. 參考資料
如果你想更詳細的了解AOP的內容，也可以參考以下資料：
1. AspectJ網站：http://www.eclipse.org/aspectj/。
2. I want my AOP, Part1, Part2, part3 （By Ramnivas Laddad）：
http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html，
http://www.javaworld.com/javaworld/jw-03-2002/jw-0301-aspect2.html，
http://www.javaworld.com/javaworld/jw-04-2002/jw-0412-aspect3.html。
3. Junit網站：http://www.junit.org。
4. Virtual Mock Objects using AspectJ with JUNIT，
http://www.xprogramming.com/xpmag/virtualMockObjects.htm。
5. AspectJ for JBuilder，http://aspectj4jbuildr.sourceforge.net/。
6. Mock Object，http://www.mockobjects.com。

Trackback地址: http://www.yculblog.com/trackback/0/621226

使用sitemesh建立复合视图 - 1.hello

使用sitemesh建立复合视图 - 1.hello  <- now

使用sitemesh建立复合视图 - 2.装饰器  

使用sitemesh建立复合视图 - 3.其它讨论 

sitemesh是opensymphony团队开发的j2ee应用框架之一，旨在提高页面的可维护性和复用性。opensymphony的另一个广为人知的框架为webwork是用作web层的表示框架。他们都是开源的，可以在www.sf.net下找到。

应用于以下大项目的例子：http://opensource.thoughtworks.com/projects/sitemesh.html

• www.jboss.org
• www.theserverside.com
• www.opensymphony.com
• www.atlassian.com

资源：

• 下载我提供的ant build的例子  
  我在j2sdk-1_4_0,tomcat4.0.3和tomcat5下测试通过，请先运行/build.bat,以生成/dist/web.war文件，然后实施到你的服务器即可。
  
• opensymphony团队的项目集合：
  http://sourceforge.net/projects/opensymphony
  
• Wiki ：http://wiki.opensymphony.com/
  
• 在sf的cvs上下载最新版本CVS

关于作者：

陈鹏，西安东软公司。作为一名狂热的程序员希望每一天都能成长进步，并希望与大家分享快乐和知识。
请用以下方式和他联系：email chen56@msn.com  

一、背景：(目录)
　　J2EE是开发企业很好的平台。它内涵非常丰富，使用人群也非常庞大，有很多最佳实践经验和优秀工具。事实证明,J2EE确实可以为复杂的企业应用提供强大的技术保障。但由于它过于复杂，开发人员缺乏足够技巧和开发经验，往往也是导致J2EE项目落马的原因。
　　这个题目可能会让您觉得有些哗众起宠的味道，但这个在J2EE潜水的小虾米如果能让您对目前的开发哪怕有一点小的触动就很满足了。我写这篇文章时已经穿好了防弹衣，期待着您的西红柿和鲜花!
　　看了一些论坛里的帖子，让我很疑惑的是为什么EJB看来是如此的成功?但我却发现在 本公司和其它竞争对手以及我兄弟们中的牛公司中使用EJB的是少之又少。
疑惑!谁动了我的EJB？
　　Bea的 WebLogic是如此的出色，以至于WebLogic 8出来后 我们这些日日夜夜的不停推磨的驴子简直都可以洗洗睡了。
　　但具有讽刺意味的是倘若你问我们为什么要买WebLogic，因为sun的 iplanet不停的挂掉，我们终于受不了，也不敢再相信sun one server。选择WebLogic因为我们需要一个可靠的web server支持jsp罢了。
　　首先说明我不是EJB的反对者，我依然希望EJB能在数据持久层开发中发挥重要作用。我将在正文中讲我的想法，我想BEA的WebLogic可以带给我们更多好的东西。

二、开发环境 (目录)
　　> 操作系统：WINDOWS 2000
　　> J2EE应用程序服务器：BEA WEBLOGIC SERVER 6.1
　　> 开发工具：EOS studio33 （其实就是对WEBLOGIC studio的改造加入了一些财政开发常用的库让业务流程能象工作流的开发），DEMO例子都是在eclipse下开发的与这开发工具无关。
　　> 数据库：ORACLE 9I

三、系统开发框架(目录)
　　下面是我们公司和XXX一块合作开发的一套国库县乡系统，为了提高开发效率我们对WebLogic 6 的STUDIO开发工具作了一些改造，加入了我们的构件库。使业务能图形化开发的尝试，有点类似现在WebLogic 8的工作流的开发。这是一次不太成功的试验，但确实能带给我们一些新的东西。由于大多数用户没有相同的开发环境，我不打算对技术细节做太多描述，只写对现在J2EE开发框架有冲击的东东。
　　我们将企业系统可以划分为页面层、业务流程层、服务层、对象层和数据层五个层次。从实现各层的技术标准看，页面层技术有JSP及portal等，业务流程技术有WfMC及BPML等，服务层技术有EJB及Web Services、对象技术有JDBC、XML，数据技术有各类数据库产品，如：DB2、Oracle、SQL Server，以及SQL92等相关标准。

图一

　　该系统就是在这些技术标准基础上，对各技术层次上的业务内容实现了面向构件的封装。构件的最终实现技术仍为各层次的标准技术。将页面层业务内容封装为页面构件及页面模版构件，将流程业务内容封装为工作流程图和页面流程构件，将服务业务内容封装为业务逻辑构件；将对象封装为运算逻辑等基础构件，将数据封装为数据构件。

3.1该开发模型的特点(目录)
　　（1） 从系统框架层次看，它是一个标准的MVC系统框架，是当前主流的、公认的系统框架。
　　（2） 在应用系统中，业务构件在运行时的表现为标准的EJB。在运行系统中，构件接口形式、互操作形式完全使用EJB标准。
　　（3） 基础构件都是完全符合J2EE技术标准的，包括JDBC、JMS、JSP、JNDI技术等。这些技术标准的采用使开发的应用系统成为完全符合J2EE标准的应用系统。
　　（4） 在系统配置、数据接口、内存数据管理各方面采用了XML技术标准。由于XML具有良好的自描述性和顺序无关性，利用XML标准进行数据交换、内存数据管理使系统具有更加良好的可扩展性和伸缩性。基于该开发的应用系统是一个符合XML标准的应用系统。
　　在面向构件和可视化的构件组装过程中，同样采用了XML的定义格式，使构件的组装基于XML而非代码层定义，并在应用装载时由运行支撑环境解释为标准的J2EE。这即保证了此应用系统自身的简洁性，又保持了应用系统的标准性。

3.2 层与层之间数据交互XML Data Bus(目录)
　　层间上下可互访，但不能越过相邻层通讯。层间数据交互用XML作为交互载体。见下图。

图二

3.3 数据持久层设计(目录)
　　普通的J2EE平台都不提供相关的建模与数据管理工具，而采用专用工具（如：PowerDesigner 或 Rational Rose等），这增加了多个工具间的切换和使用复杂度；另外，由于数据模型工具对是多个、异构数据库系统支持的简单性，使程序员常常需要在这些工具之外进行许多的代码编写工作。
　　它提供了专用数据模型工具（Database Designer Tools）对应用模型设计、模型管理、数据结构生成进行一体化的处理。同时，由于其工具内部内置了数据映射功能，使数据结构面对多样、异构的数据库（如:Oracle、DB2、MSSQL等）时，可以以统一的调用和对前台无影响的系统数据移植方式为前台应用提供服务。

图三

四、反思(目录)
　　看了这么多花花绿绿的图片和理论，可能把您的头都搞大了。下面汇总一下前面的内容。

4.1该模式的优点(目录)
> 严格分层，为了实现层的修改不会影响相关层的。系统采用了显示层，展现层、业务流程层、服务层、对象层和数据层六层结构。
> 层与层之间数据交互采用XML Data Bus，这样基本上实现层中修改不会影响上下两层，最多是利用映射，服务器重起一下。
> 这种模块化有利于分层开发相对的控件和图形化开发工具。
> 最令人心动的是专用数据模型工具（Database Designer Tools），只需配一下数据库连接就可以实现得到表的增删改查。
> 最让人感动的是处处用到EJB技术，可使用者从来没感觉到使用了某种特定技术，只是简单调用数据持久层的增删改查方法就OK了！

4.2借鉴(目录)
　　多么美的事情，我当初看到真是一夜未眠，最终也为后来项目不太成功打下伏笔。现在分析起来主要是：
　　XML Data Bus设计有问题，由于XML在HTTP中传数据有自身的弱点，如XML会把XML空格结点去掉，结果页面有个TEXT显示数据库某个字段aa的值test,我想把它赋空，在页面到展现层时XML自动忽略这个结点，最后数据库更新可想而知，我依然是我。
　　开发工具不稳定，某些技术不太成熟，也没有较好的编辑工具，修改一个小东西，简直有点大海捞针的味道非常考验人的耐性，开发前期很顺，到了后期，服务器无名火到处发，现象重现率也不高，系统正常都不知怎么正常的，维护简直是噩梦。
　　简单是我们程序开发中一个很重要的原则，简单会减少我们出错的概率，而且即使出现错误也能很快纠正。

4.3反思(目录)
　　虽然有这样或那样的失败原因，但凭心而论，这套J2EE解决方案确实还是有其独特的魅力。
　　我的体会主要有这样的几点：
> 　J2EE开发肯定需要分层，但不宜分层太多。MVC的方式比较好。从开发和维护角度考虑，分四层结构比较合适。

图四

>　数据持久层好写但不容易写好，这是系统最基础也是最核心的部件，一个程序的好坏很大关系是它决定的。EJB想说爱你真的不容易，O/R面向对象的数据库编程对一些简单的业务操作能提升很大的开发效率，可惜我们的数据库很复杂，简单说说我们的权限判断，严肃到数据库表的哪个字段用户当前职责是可读还是可写，而且这些关系大量SQL执行找到最接近的数据访问权限，我想目前除了IBATIS勉强满足外，Hibernate敢都不敢想。非常希望BEA的WEBLOGIC能开发类似EOS的专用数据模型工具（Database Designer Tools），不要让我知道我在用什么技术调用数据库，我只用告诉它需要对数据库做什么操作就行，最好能像MS的工具箱一样，给个控件告诉它对应什么表，该做什么操作，以及该操作需要什么前提条件。条件只是按它映射命名的对象就可以自动组合合适的SQL或采用相应的EJB操作。我们真得不想关心，你是用JDBC还是EJB实现的，我们只需要最佳的效果，这个WEBLGIC完全可能根据当前SERVER容器的支持环境做出。
>　层与层间数据传递用VO对象，也可用串行化实现。
>　MVC中M的开发业务层和数据层组织形式采用DAO模式比较好。事务放在业务层，采用J2EE容器的事务声明方式。
　　可能这些想法并没太多新鲜的成分，但我需要强调的是数据持久层的设计应该有构件化的产品，开发人员不需要了解如何得到是通过EJB或是JDBC从数据库中得到数据，WEB SERVER容器中提供什么服务，它可以自动选择方式，当然也可手工设置。
　　这个问题是可以得到很好解决的，注意我DAO的设计思想，数据持久层不需要考虑事务等一些复杂的问题，它只需简单对表做增删改查的工作。

开发人员需要做的是二件事
>　开发人员配置数据库连接，工具能自动建立表与数据持久层对象的映射
>　开发人员利用构件化的工具包（属性包含数据持久层对象名和调用条件（VO对象），方法有增删改查）简单配置，然后装配到业务层就能实现业务逻辑的演练。
　　这个开发需要注意它是个独立的层，不会依赖某一数据库或WEB SERVER容器，是个通用的数据持久层的解决方案。我相信BEA公司会把这种设想做得更好！
　　开发人员需要数据持久层开发效率和性能，我们再使用EJB，但不需要过多陷于EJB中。

五、较理想的J2EE解决方案(目录)
5.1 J2EE分层(目录)
　　涉及到的java类可以分为这么几种：
>　VO/command类。
　　用于各层之间传输数据用。只有set,get方法。值对象尽量要通用性强。属性方法多。
>　controller类
　　用于处理用户提交请求。建议将多个有紧密关系的功能点放在一个类里。如对计划的浏览，提交，修改，就可以放在一个类里。Controller类负责前台的，不重要的数据校验。并调用façade类完成业务。
>　façade类
　　管理类或者门面类。一个模块只能有一个这样的类，所有的controller类都调用该类，而不直接调用DAO类。该类里面起事务处理，本身没有功能，调用DAO类完成功能。
>　DAO类
　　负责具体的数据库存取操作。原则上一个表对应一个DAO类，也可以按对象来建立类。
　　这个MVC开发方式本身可能没有太多新鲜的地方，其相同点在这里就不说了，本文具体就怎样构件M？也就是业务逻辑层和数据持久层的架构。

5.2设计目标(目录)
　　充分利用OOP设计的优势
　　避免了不必要的复杂
　　具有可维护性、可扩展性
　　避免任何特定平台或非标准化
　　不重新开发已有的东西目前Spring的Ioc模式实现的BeanFactory和AOP，编制程序时，只要写被调用者的接口代码，具体子类实例可通过配置实现，它不依赖特定平台，你可一全部用它的框架，也可以只用其中一部分。
　　这种新的架构出现，使我觉得以下情况实现成为可能！
　　数据持久层设计图形化构件化开发能成为可能，它只管和数据库数据交互更新，不要担当太多的责任。而业务逻辑层自我定制构件将会变得非常简单，而且借鉴J2EE的EJB事务容器申明也得到解决。业务逻辑层实现有点象小时侯搭积木一样轻松的把数据持久层构件组合就能实现。下面将就数据持久层构件化和业务逻辑层分别论述。

5.3 J2EE数据持久层开发(目录)
　　数据持久层设计构件化开发可能？
　　数据持久层设计目标：
　　操作简单，我们希望只需将数据连接配置好，然后我们将构件与数据库具体表对应上，接下来告示它操作类型，传入条件参数（VO类）后，余下的任务全有他完成。数据持久层只管和数据库数据交互更新，本身只对表的增删改查的动作，非常简洁，硬编码也不会太复杂。
　　调用只需要利用Spring的BeanFactory简单配置，就可在业务处理层直接调用。这个过程只是简单改写一下配置文件，其图形化，非常容易实现。
　　测试，我们在数据持久层用的是接口编程模式，利用JUIT或Spring本身资源读取API很容易写测试方法。
　　维护和修改很方便。由于是具体子类实例可通过配置实现，非常方便修改和扩展。
　　目前有一些类似产品，可惜都是依赖某一特定平台或技术，你要么全部按他的规范做，要么全部放弃。它使你在某一方面方便的却在另外方面限制你，让你没法施展拳脚。
　　当前比较恰当的组合Spring的BeanFactory+IBATIS，能较好满足轻量级系统的开发。我希望BEA公司的WEBLOCIC能在这方面为我们提供精彩的解决方案。
　　借鉴Spring的BeanFactory和AOP技术和BEA在EJB的造诣，BEA完全可能把它做得更好！而且基于以上分析，技术难度上不会太大。我们有理由期待数据持久层设计构件化图形化的到来。我觉得它的出现应该除了前面的特点，还应有下面的特点：
　　开发者，不需要知道数据持久层是用EJB或是JDBC实现的具体细节。该构件能自动根据服务容器的支持，选择是EJB或是JDBC实现。
　　EJB本身没有错，错在它能力太多，让使用者无法驾御。我们开发人员关注的是数据持久层的本身功用和性能，我们不管你是用EJB或是JDBC实现的。我们需要简单持久性能优良的解决方案。请不要让EJB做太多的实质是数据持久层不要做太多。

5.4业务逻辑层的设计(目录)
　　面向接口的开发，它具有很强的灵活度和扩展性。
　　业务逻辑层调用也用Spring的BeanFactory组合，这样在数据持久层设计构件化的同时，我们业务逻辑层自我定制构件将会变得非常简单。
　　我们将数据持久层中的事务处理提到业务逻辑层的理由是不用多说的。我们只需简单对SPRING的bean管理的配置文件增加拦截代理对象，为了给业务逻辑对象增加事务处理。其简单声明如下：

<!-- Transaction manager for a single JDBC DataSource -->
     <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
            <property name="dataSource"><ref local="dataSource"/></property>
     </bean>
     <bean id="systemManager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
            <property name="transactionManager"><ref local="transactionManager"/></property>
            <property name="target"><ref bean="业务逻辑"/></property>
            <property name="transactionAttributes">
                   <props>
                          <prop key="query*">PROPAGATION_SUPPORTS,readOnly</prop>
                          <prop key="*">PROPAGATION_REQUIRED</prop>
                   </props>
            </property>
     </bean>

　　transactionAttributes属性可以设置事务处理的方式，事务隔离级别，是否只读三个属性，用逗号隔开。事务隔离级别各数据库系统不完全支持，一般不设置，用默认的即可。
　　事务处理选项有如下几个：（前面2个常用）
　　PROPAGATION_REQUIRED － 需要事务处理。如果当前不存在事务环境，则创建一个；
　　PROPAGATION_SUPPORTS － 如果当前存在事务环境，则作为其中的一部分。如果不存在，则按非事务方式执行；
　　PROPAGATION_REQUIRES_NEW － 需要事务处理。并总是开启一个新事务。如果已经存在事务环境，则挂起之；
　　PROPAGATION_MANDATORY － 执行到指定方法时，必须已经存在事务环境，否则出错；
　　PROPAGATION_NEVER － 不支持事务操作，如果存在事务环境会出错；
　　PROPAGATION_NOT_SUPPORTED － 不支持事务操作。如果存在事务，则挂起。　　如果要追求好的性能，我们可以在此定义事务精确到到某一方法的某一异常起事务回滚。
　　WEBLOGIC SERVER可以协调涉及多个资源的事务时，JTA的许多高级事务协调特性才能发挥。对一个跨数据库资源的事务，将采用两个阶段提交（Two-Phase Common,2PC）技术处理。实际上对用户而言2PC技术是透明的。在应用JTA驱动程序时，需要连接多个资源，指定针对这些资源的操作等。只要XA兼容，WEBLOGIC就会把这些资源集成到一个事务中，使所有的资源相互协调一致工作，或者都成功或者都失败。TXDATASOURCE建立与多个XA兼容资源之间的桥实现。JAT负责处理JTA事务与底层资源的相互协调。

　　要实现这种功能只需将<bean id= transactionManager >换成如下写法就可：

<bean id=” transactionManager”class=”org.springframework.transaction.jta.JtaTransactionManager”/>

5.5 业务层和数据持久层数据总线(目录)
　　业务层和数据持久层交互为何采用VO对象而不是XML或SQL字符串作为传递参数？
　　①前者分层明晰，后者把SQL生成放在业务层，在业务类中硬编码SQL，导致代码难于维护和扩展SQL代码到处出现在你的类代码中。这样的好处是写代码效率很高，对于小型应用程序或者原型，这样是可行的。缺点是直接耦合了你的业务类与关系数据库结构。业务层不应该做数据层的工作。而且业务层或数据库字段变动，会引起两层修改。维护不方便，也不利于数据持久层的接口抽象。
　　②前者更加符合面向对象的开发思想。面向对象应用程序可以使用关系数据库作为持久机制而不需要在程序中使用嵌入SQL。后者没有仔细考虑对持久机制维护和管理的应用程序带来的继承脆弱性。
　　③前者增加VO对象时，业务和数据持久层代码几乎不需任何修改。可理解性和兼容性都比后者好。

六、实践(目录)
　　前面说了不少理论的东东，大家可能都有点厌倦了，下面通过一个实例解释一下。限于篇幅，我将项目中常用的分页实现作为例子给大家说说。由于目前数据持久层还没有比较好的构件化开发工具，现用IBATIS代替。大部分内容都不会讲太细的细节，因为我假定读者有SPRING和IBATIS的基础知识。限于篇幅，我们重点放在业务逻辑和数据持久层的实现上，详细内容见源码，有比较详细的解释。

6.1开发思路(目录)
　　分页逻辑：页面需要保存以下参数：
　　总行数：根据sql语句得到总行数　　　每页显示行数：设定值pageSize　　　当前页数：请求参数page
　　页面根据当前页数和每页行数计算出当前页第一行行数，定位结果集到此行，对结果集取出每页显示行数的行即可。
　　在SESSION存放数据列表是这么考虑的：对于大量数据，比如10000条，肯定不能一次全取出来。通常是每次取一页的数据，如20条，其实效率也不高。 最好是每次取出来(比如)10页的数据，放在session里。这样，翻10页才会查一次数据库。

图五

6.2系统设计(目录)
6.2.1总体设计(目录)
　　后台数据持久层，采用DAO模式；中间逻辑层，采用Facade模式；前端Web层，采用MVC结构，使用JSP作为视图。其组装详见下图：

图六

　　利用Spring的Ioc模式实现的BeanFactory非常方便将以上组装实现。

6.2.2 数据持久层设计(目录)
　　数据持久层与数据库联系非常简单，在SPRING的配置文件中配置如下两步就可。
　　第一步：设置iBATIS

<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
         <property name="configLocation">
         <value>WEB-INF/sqlMap-config.xml<!-- iBATIS配置文件--></value>
         </property>
</bean> 

　　第二步：数据访问层(DAO)对象与数据库配置和iBATIS配置联系

<bean id="userDao" class="cn.com.mofit.demo.system.dao.SqlMapUserDAO">
         <property name="dataSource">
                  <ref local="dataSource"/>
         </property>
         <property name="sqlMapClient">
                  <ref local="sqlMapClient"/>
         </property>
</bean>

　　接下来业务逻辑就可使用这些数据持久层的方法了。
　　你看不是很方便，开发者在代码编写中从来没感觉到用到Spring什么东东，而且简化IBATIS操作数据库的步骤。
　　数据持久层的开发任务是将业务层传过来VO值对象转化为数据库中对满足条件的特定操作。
　　IBATIS引入了动态映射机制，根据配置文件中设定的SQL动态生成规则，创建相应的SQL语句。通过
等一些IBATIS的SQL动态生成规则组合很方便的实现VO值对象到数据库操作映射。

6.2.3 业务逻辑层设计(目录)
　　该类是系统管理模块的facede类。所有对系统管理模块的业务操作都应当通过该类完成。
　　该类会通过配置文件为所有方法增加事务处理。
　　建议类里面的方法都加上如下前缀，以方便用指定的命名规则设置事务处理级别：
　　queryXXX() － 不需要，或者只读事务
　　addXXX() － 需要事务处理
　　removeXXX() － 需要事务处理
　　updateXXX() － 需要事务处理
　　XXXX() － 其他方法，需要事务处理
　　这样，我在TransactionProxyFactoryBean的配置里就可以这样设置：

      <property name="transactionAttributes">
           <props>
               <prop key="query">PROPAGATION_SUPPORTS</prop>
               <prop key="">PROPAGATION_REQUIRED</prop>
           </props>
       </property>

　　由于该类的特殊性和事务处理，建议类里面不要有无谓的辅助方法。
　　我们在CONTROL层引用的业务层实质是业务逻辑层加上事务后的业务逻辑接口。

6.2.4 WEB层设计(目录)
　　Controller类负责前台的，不重要的数据校验。并调用façade类完成业务。非常干净利落。

图七

　　对应的SPRING配置文件

<!-- 用户登录处理类 -->
<bean id="do_login" class="cn.com.mofit.demo.system.web.UserLogAction">
<property name="formView"><value>login</value></property>
<property name="successView"><value>main</value></property>
<property name="systemManager"><ref bean="systemManager"/></property>
</bean>

    <!-- 用户列表浏览类 -->
<bean id="do_browse" class="cn.com.mofit.demo.system.web.browseUserAction">
<property name="systemManager"><ref bean="systemManager"/></property>
</bean>

　　非常轻松的将加上事务后的业务逻辑接口引到控制层，页面流配置也类似STRUTS。
UserLogAction继承SimpleFormController，该子类非常适合处理表单提交事件。 它的处理流程是这样的：
　　get请求来到时，这样处理：
　　1) 请求传递给一个controller对象
　　2) 调用formBackingObject()方法，创建一个command对象的实例。
　　3) 调用initBinder()，注册需要的类型转换器
　　4) 调用showForm()方法，返回准备呈现给用户的视图
　　5) 调用referenceData()方法，准备给用户显示相关的数据。如用户登录需要选择的年度信息
　　6) 返回formView指定的视图
　　post请求来到时，这样处理：
　　1) 调用formBackingObject()方法，创建一个command对象的实例。
　　2) 将请求传来的参数写入command对象
　　3) 如果设置为要求验证，则调用validator类进行数据验证
　　4) 调用onBindAndValidate()方法，该方法允许自定义数据绑定和校验处理
　　5) 调用onSubmit()方法，进行业务逻辑处理
　　结合我们的设计我们可以用command对象，直接将页面数据通过控制对象传给业务逻辑处理，当中都不需要类型转换，非常方便。是不是很合开发者的胃口。

6.2.5 总 结 (目录)
　　这个事例非常简单，但还是能说明Spring的Ioc模式实现的BeanFactory和AOP确实能给我们开发带来极大方便。我想如果我们有工具将BeanFactory的配置文件生成图形化的话，将会极大提高我们的开发效率。
　　以前构建一个持久层是惊人的困难，现在我们想一下结合iBATIS数据持久层的开发，我们将数据持久层构件化是否是个非常简单的事，现在需要做的仅仅是IBATIS的sqlMap文件生成的图形化工具，然后是几个摸版化增删改查的方法。业务逻辑层对它们的装配利用Spring的BeanFactory也能轻松实现。
　　这是个轻量级的J2EE开发的图形化构件化的解决方案，那么我们EJB老大哥呢？
　　我想如果单一抛开EJB那么多功能不说，我想就EJB专注做好数据持久层设计构件化这个工作，它有许多优势的。现在已经有人在这方面做了比较大的突破。
　　请不要让我们一起重复数据持久层开发的辛劳，我们不管你用什么技术，我们只是需要较佳从数据库中交互数据的构件，让我们在这方面学学MS，而且我们能比它做得更好！
　　我们需要数据持久层构件化，结合Spring的Ioc模式实现的BeanFactory原理，简单的让业务逻辑组装，要是这两者都有方便的可视化工具。我想下次开发我们仅仅需要动一下鼠标，拖拉几个控件，一切搞定。而这离我们到底有多远，我觉得就差最后的一步！

6.3源码下载(目录)
　　本程序在JDK4.1,TOMCAT 5.0或WebLogic 8.1上测试通过。代码有详细注释，大家看过就能上手。

　　点击这里下载demo!

七、BEA能为我们做更多(目录)
　　Bea的 WebLogic出色表现有目共睹，尤其是现在WebLogic 8。现在应用服务越来越复杂，我这个用WebLogic6的人突然看到WebLogic 8会欣喜又不知所措，我们还希望Bea能给我们较简单的解决方案。
　　突破口在哪呢？就是数据持久层的开发，数据持久层的不依赖某一特定服务器的构件化图形化开发做好，一切将变得EASY！前面有Spring的Ioc模式实现的BeanFactory和AOP和轻量级数据库解决方案IBATIS(Hibernate)做急先锋，我们觉得数据持久层构件化时代已经到来！这样WebLogic运行见下图：

图八

　　BEA能为我们做得更多？！
　　BEA下个春季，值得我们期待！

八、总结(目录)
　　这篇文章对我来说是个挑战，但一直以来J2EE开发的快乐与痛苦刺激着我前行。我觉得我们应该为这作些什么。
　　题目选得有点大，我有几次想放弃，但我老婆APPLE一直鼓励着我，让我在痛苦中成长。
　　我希望将来的J2EE开发不再会有EJB该如何使用的疑问。因为开发者本身都不会感觉EJB的存在。限于本人水平和理解层次，可能会有许多误解，期待着与您交流和争论！

相关资源下载(目录)
　　JDK 1.4.2可以从http://java.sun.com下载。
　　Spring framework 1.1可以从http://www.springframework.org
　　iBatis 2.0可以从http://www.ibatis.com下载。
　　Tomcat 5.0、Ant 1.6可以从http://www.apache.org下载。
　　WebLogic Server / Workshop 8.1可以从http://commerce.bea.com下载。
　　oracle9I的JDBC驱动，commons-dbcp下载

参考资料(目录)
　　Wrox - Professional J2EE with BEA WebLogic Server
　　J2EE Applications and BEAWebLogic Server
　　Expert One-on-One J2EE Development without EJB
　　Expert One-on-One J2EE Design and Development by Rod Johnson
　　部分图片来自公司培训幻灯片

关于作者(目录)
　　关于作者：
　　周必奎（dev2dev ID:zhoubikui），软件工程师，从事J2EE开发
　　电子邮件：zhoubikui@eyou.com
　　地址：财政部信息网络中心北京兴财信息有限公司

package org.springframework.beans.factory;

import org.springframework.beans.BeansException;

/**
 * The root interface for accessing a Spring IoC container.
 *
 * <p>This interface is implemented by objects that hold a number of bean definitions,
 * each uniquely identified by a String name. Depending on the bean definition,
 * the factory will return either an independent instance of a
 * contained object (the Prototype design pattern), or a single
 * shared instance (a superior alternative to the Singleton
 * design pattern, in which the instance is a singleton in the scope of
 * the factory). Which type of instance will be returned depends on the bean
 * factory configuration - the API is the same. The Singleton approach is
 * more useful and more common in practice.
 *
 * <p>The point of this approach is that the BeanFactory is a central registry
 * of application components, and centralizes configuration of application
 * components (no more do individual objects need to read properties files,
 * for example). See chapters 4 and 11 of "Expert One-on-One J2EE Design and
 * Development" for a discussion of the benefits of this approach.
 *
 * <p>Note that it is generally better to rely on Dependency Injection
 * ("push" configuration) to configure application objects through setters
 * or constructors, rather than use
 * any form of "pull" configuration like a BeanFactory lookup. Spring's
 * Dependency Injection functionality is implemented using BeanFactory
 * and its subinterfaces.
 *
 * <p>Normally a BeanFactory will load bean definitions stored in a configuration
 * source (such as an XML document), and use the org.springframework.beans package
 * to configure the beans. However, an implementation could simply return Java
 * objects it creates as necessary directly in Java code. There are no constraints
 * on how the definitions could be stored: LDAP, RDBMS, XML, properties file etc.
 * Implementations are encouraged to support references amongst beans, to either
 * Singletons or Prototypes.
 *
 * <p>In contrast to the methods in ListableBeanFactory, all of the methods in this
 * interface will also check parent factories if this is a HierarchicalBeanFactory.
 * If a bean is not found in this factory instance, the immediate parent is asked.
 * Beans in this factory instance are supposed to override beans of the same name
 * in any parent factory.
 *
 * <p>Bean factory implementations should support the standard bean lifecycle interfaces
 * as far as possible. The maximum set of initialization methods and their standard
 * order is:<br>
 * 1. BeanNameAware's setBeanName<br>
 * 2. BeanFactoryAware's setBeanFactory<br>
 * 3. ApplicationContextAware's setApplicationContext (only applicable if running
 * in an application context)<br>
 * 4. postProcessBeforeInitialization methods of BeanPostProcessors<br>
 * 5. InitializingBean's afterPropertiesSet<br>
 * 6. a custom init-method definition<br>
 * 7. postProcessAfterInitialization methods of BeanPostProcessors
 *
 * <p>On shutdown of a bean factory, the following lifecycle methods apply:<br>
 * 1. DisposableBean's destroy<br>
 * 2. a custom destroy-method definition
 *
 * @author Rod Johnson
 * @author Juergen Hoeller
 * @since 13 April 2001
 * @see BeanNameAware#setBeanName
 * @see BeanFactoryAware#setBeanFactory
 * @see InitializingBean#afterPropertiesSet
 * @see DisposableBean#destroy
 * @see org.springframework.beans.factory.config.BeanPostProcessor#postProcessBeforeInitialization
 * @see org.springframework.beans.factory.config.BeanPostProcessor#postProcessAfterInitialization
 * @see org.springframework.beans.factory.support.RootBeanDefinition#getInitMethodName
 * @see org.springframework.beans.factory.support.RootBeanDefinition#getDestroyMethodName
 * @see org.springframework.context.ApplicationContextAware#setApplicationContext
 */
public interface BeanFactory {

 /**
  * Used to dereference a FactoryBean and distinguish it from beans
  * <i>created</i> by the FactoryBean. For example, if the bean named
  * <code>myEjb</code> is a FactoryBean, getting <code>&myEjb</code> will
  * return the factory, not the instance returned by the factory.
  */
 String FACTORY_BEAN_PREFIX = "&";

 /**
  * Return an instance, which may be shared or independent, of the given bean name.
  * This method allows a Spring bean factory to be used as a replacement for
  * the Singleton or Prototype design pattern.
  * <p>Callers may retain references to returned objects
  * in the case of Singleton beans.
  * <p>This method delegates to the parent factory if the
  * bean cannot be found in this factory instance.
  * @param name the name of the bean to return
  * @return the instance of the bean
  * @throws NoSuchBeanDefinitionException if there is no bean definition
  * with the specified name
  * @throws BeansException if the bean could not be obtained
  */
 Object getBean(String name) throws BeansException;

 /**
  * Return an instance (possibly shared or independent) of the given bean name.
  * <p>Behaves the same as getBean(String), but provides a measure of type safety by
  * throwing a Spring BeansException if the bean is not of the required type.
  * This means that ClassCastException can't be thrown on casting the result correctly,
  * as can happen with getBean(String).
  * @param name the name of the bean to return
  * @param requiredType type the bean must match. Can be an interface or superclass
  * of the actual class, or null for any match. For example, if the value is
  * Object.class, this method will succeed whatever the class of the returned instance.
  * @return an instance of the bean (never null)
  * @throws BeanNotOfRequiredTypeException if the bean is not of the required type
  * @throws NoSuchBeanDefinitionException if there's no such bean definition
  * @throws BeansException if the bean could not be created
  */
 Object getBean(String name, Class requiredType) throws BeansException;

 /**
  * Does this bean factory contain a bean definition with the given name?
  * <p>Will ask the parent factory if the bean cannot be found in this factory instance.
  * @param name the name of the bean to query
  * @return whether a bean with the given name is defined
  */
 boolean containsBean(String name);

 /**
  * Is this bean a singleton? That is, will getBean() always return the same object?
  * <p>Will ask the parent factory if the bean cannot be found in this factory instance.
  * @param name the name of the bean to query
  * @return is this bean a singleton
  * @throws NoSuchBeanDefinitionException if there is no bean with the given name
  */
 boolean isSingleton(String name) throws NoSuchBeanDefinitionException;

 /**
  * Determine the type of the bean with the given name.
  * More specifically, checks the type of object that getBean would return.
  * For a FactoryBean, returns the type of object that the FactoryBean creates.
  * @param name the name of the bean to query
  * @return the type of the bean, or null if not determinable
  * @throws NoSuchBeanDefinitionException if there is no bean with the given name
  * @since 1.1.2
  * @see #getBean
  * @see FactoryBean#getObjectType
  */
 Class getType(String name) throws NoSuchBeanDefinitionException;

 /**
  * Return the aliases for the given bean name, if defined.
  * <p>Will ask the parent factory if the bean cannot be found in this factory instance.
  * @param name the bean name to check for aliases
  * @return the aliases, or an empty array if none
  * @throws NoSuchBeanDefinitionException if there's no such bean definition
  */
 String[] getAliases(String name) throws NoSuchBeanDefinitionException;

}