public class RefBean {
       public String getAddress() {
              return address;
       }
       public void setAddress(String address) {
              this.address = address;
       }
       public String getZipcode() {
              return zipcode;
       }
       public void setZipcode(String zipcode) {
              this.zipcode = zipcode;
       }
       private String zipcode=null;
       private String address=null;
}

Spring中IOC贯穿了其整个框架，但正如martinflower所说：“saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels”，IOC已经称为框架设计中必不可少的部分。就实现上来讲Spring采取了配置文件的形式来实现依赖的注射，并且支持Type2 IOC（Setter Injection）以及Type3 IOC（Constructor Injection）。

    Spring中IOC的实现的核心是其Core Bean Factory，它将框架内部的组件以一定的耦合度组装起来，并对使用它的应用提供一种面向服务的编程模式(SOP：Service-Orient Programming)，比如Spring中的AOP、以及持久化（Hibernate、ibatics）的实现。

    首先从最底层最基础的factory Bean开始，先来看org.springframework.beans.factory.Bean

    Factory接口，它是一个非常简单的接口，getBean方法是其中最重要的方法，Spring通常是使用xml来populate Bean，所以比较常用的是XMLFactoryBean。

    用一个简单的示例看一下其用法。首先写下两个Bean类：

    ExampleBean 类：

public class ExampleBean {
       private String psnName=null;
       private RefBean refbean=null;
       private String addinfo=null;
       public String getAddinfo() {
              return getRefbean().getAddress()+getRefbean().getZipcode();
       }
       public String getPsnName() {
              return psnName;
       }
       public void setPsnName(String psnName) {
              this.psnName = psnName;
       }
       public void setRefbean(RefBean refbean) {
              this.refbean = refbean;
       }
      public RefBean getRefbean() {
              return refbean;
       }
       public void setAddinfo(String addinfo) {
              this.addinfo = addinfo;
       }
}
 

 RefBean类：

public class RefBean {
       public String getAddress() {
              return address;
       }
       public void setAddress(String address) {
              this.address = address;
       }
       public String getZipcode() {
              return zipcode;
       }
       public void setZipcode(String zipcode) {
              this.zipcode = zipcode;
       }
       private String zipcode=null;
       private String address=null;
}

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
  <bean id="exampleBean" class="test.ExampleBean">
    <property name="psnName"><value>xkf</value></property>
    <property name="refbean">
       <ref bean="refBean"/>
    </property>
  </bean>
  <bean id="refBean" class="test.RefBean">
  <property name="address"><value>BeiJing</value></property>
  <property name="zipcode"><value>100085</value></property>
  </bean>
</beans>

然后可以写个测试类来测试，当然，需要Spring中的Spring-core.jar以及commons-logging.jar，当然在elipse中可以通过安装spring-ide插件来轻松实现。

public class Test {
       public static void main(String[] args){
              try{
              Resource input = new ClassPathResource("test/Bean.xml");
              System.out.println("resource is:"+input);
              BeanFactory factory = new XmlBeanFactory(input);
              ExampleBean eb =
              (ExampleBean)factory.getBean("exampleBean");
              System.out.println(eb.getPsnName());
              System.out.println(eb.getAddinfo());
       }
       catch(Exception e){
              e.printStackTrace();
       }
}

介绍

其实IOC模式并不是什么新的东西，它是一种很普遍的概念（或者说结构），GoF中的Template Method 就是IOC的结构。顾名思义，IOC即控制反转。著名的好莱坞原则：“Don’t Call us, We will call you”，以及Robert C. Martin在其敏捷软件开发中所描述的依赖倒置原则（Dependency Inversion Principle, DIP）都是这一思想的体现。Dependency Injection是Martin Flower对IOC模式的一种扩展的解释，下面我们从一个简单的实例开始。

考虑一个Button来控制Lamp的开和关。

如下的类图，并写下了代码。

public class Button {

       private Lamp lnkLamp;

       public void poll() {

              lnkLamp.Turnon();

       }

}

但是马上发现这个设计的问题，Button类直接依赖于Lamp类，这个依赖关系意味着当Lamp类修改时，Button类会受到影响。此外，想重用Button类来控制类似与Lamp的另外一个对象则是不可能的。即Button控制Lamp，并且只能控制Lamp。

显然，我违反了“高层模块不应该依赖于底层模块，两者都应该依赖于抽象；抽象不应该依赖于具体实现，细节应该依赖于抽象” 这一原则（DIP原则）。

考虑到上述问题，自然地想到应该抽象出一个接口，来消除Button对Lamp的依赖，于是设计如下：

    这样，我们倒置了Button对Lamp的依赖关系，使得Lamp依赖于SwitchableDevice接口，SwitchableDevice并没有依赖于Button类，任何知道如何操纵该接口的对象都可以控制Lamp。同时Button不只是可以控制Lamp，还可以控制同样实现SwitchableDevice接口的如Computer、Cell Phone等等。回头想想，这种做法好像似曾相识，拍拍脑袋，哦！这不是GoF策略（Strategy）模式吗？！正是，不经意间我就应用了设计模式（有点得意哦~~~~）。

现在再来考虑一个问题，刚才的做法虽然倒置了依赖关系，但是如果将Button作为一个应用程序来控制Lamp或者同样实现SwitchableDevice的Computer、Cell Phone等，则代码可能如下：

public class Button {

private SwitchableDevice lnkLamp;

public Button(){

    lnkLamp= new Lamp();

}

…

}

也就是说Button和Lamp之间仍然存在《creates》这样的依赖关系。

为了解除这种依赖关系，首先看GoF能作些什么。显然，这个地方应该用Factory模式，将对象的创建交给Factory Class来处理，这样虽然解开了Lamp组件与我们应用程序Button之间的耦合关系，但是组件的创建仍然是显式的（explicitly），在组件更改时仍需要重新编译。

另外，通过一个ServiceLocator去look up实现类也是一种解除耦合的办法，看到这儿，你不禁会想EJB不就是这么实现的嘛，U are Right! Rod Johnson 在其大作J2EE without EJB中称这种方式为Dependency Look up，但这种方式也有其弊端，比如无法脱离容器环境，以及不利于Unit test等。

“Don’t Call us, We will Call you”，这个原则启示我们应该换一个思路，不应该在应用类中创建具体对象的实例，而是应该将具体对象实例的创建插入(plug)或者说注射（inject）到应用类中，这大概是依赖注射名称的由来吧。

这种实现方式需要在应用类以及调用组件之间建立一个assembler来解除两者之间的依赖，看起来与前面的方式没有太大区别，来看一下结构：

    仔细查看会发现还是有比较大的不同，依赖关系是相反的，也就是说这个过程中依然倒置了依赖关系。Lamp通过Assembler将其创建过程注射到了Button中，从而消除了两者之间的耦合，增加了灵活性。

下面我们看一下具体的实现，在PicoContainer以及Spring中有着其不同的实现，分别代表了两种类型的Dependency Injection, 即Constructor Injection 和Setter Injection。

private MutablePicoContainer configureContainer() {

        MutablePicoContainer pico = new DefaultPicoContainer();

        pico.registerComponentImplementation(SwitchableDevice.class, Lamp.class);

        pico.registerComponentImplementation(Button.class);

        return pico;

}

然后可以通过MutablePicoContainer的getComponentImplementation方法获得实现类，调用其poll方法控制Lamp的开关，这样一来，两者之间的耦合通过PicoContainer提供的Assembler完全消除了。

Spring则通过一个XML格式的配置文件，将两者联系起来，使用时，通过ApplicationContext获得Button Bean，再调用其方法实现，同样也消除了耦合关系

　　没有一种新技术是凭空诞生的，它的萌芽或胚胎总是或多或少显现于以前的技术中，Jive论坛是大家潜心研究的设计型应用程序，其相关解析可见本栏的GoF设计模式专栏。

　　Jive和Spring同为由JavaBeans组成的J2EE Web系统，Jive作为早期成功设计案例，其主要架构成为大多数纯JavaBeans系统的流行架构，Spring也不例外。

　　Spring框架除了是一种Web层应用框架，还提供了访问EJB层的接口，也有JDBC/ORM的直接操作。Spring框架主要魅力是使用IoC模式和AOP实现了Jive系统的通用功能，从而使得Jive这样的纯JavaBeans架构设计可以重用在其它系统中。

　　如果你感慨于Jive的设计理念，但是又苦于无法重用其设计时，Spring框架已经帮你实现了。

　　同时也要注意到：Spring框架类似“杂烩”，它包含了很多J2EE应用的工具，类如对EJB的调用，它的MVC与Struts JSF也是相竞争的，以纯Ioc和AOP设计来说，Spring框架也是一种很重的(Heavy、Weight)框架。Spring框架是复杂的，如果想以Spring替代EJB，那么无疑按了葫芦浮起瓢。

　　将Jive论坛和Spring框架联系起来，会帮助更多理解设计模式的程序员迅速掌握最新的设计思潮，而不是一种跳跃式的强迫接受。如果你对Jive有很好的研究，将会发现Spring框架是Jive设计的更加通用的提升。

　　在Jive中,ForumFactory是整个系统的入口和突破点，Jive通过ForumFactory将整个系统掌控在一个工厂模式下，这样做的好处是：便于控制系统的JavaBeans，例如，客户端通过ForumFactory可创建一个Forum或访问一个Forum，但是是否有权限访问呢？如下图：

　　
　　 Jive通过ForumFactory将这种访问引导到相应的Proxy类去，如ForumFactoryProxy类等，通过代理模式对这些类进行权限控制访问。这是代理模式的一个主要用处，但是研读Jive的代理模式会发现，要为每个类实现一个Proxy类，非常琐碎，有没有更优雅的方式呢？ 当然使用动态代理。

　　Spring框架基本是抽象上述设计，Spring框架对所有JavaBeans的管理也是基于一个总入口Bean Factory机制，不同的是，BeanFactory可以 管理所有应用的JavaBeans，使用者只要将自己的JavaBeans通过配置文件告诉BeanFactory，那么BeanFactory将会加载这些JavaBeans，例如：

　　<beans>
　　　　<bean id="exampleBean" class="eg.ExampleBean"/>
　　　　<bean id="anotherExample" class="eg.ExampleBeanTwo"/>
　　</beans>

　　在Jive中，ForumFactory加载Jive自己的JavaBeans是通过工厂实现DbForumFactory实现的，如下代码，DbForumFactory引发了后台一系列功能实现，这是纵向，而return new ForumFactoryProxy这个语句则类似引来一个切面，从一个横向方面实现了权限访问等功能：

　　既然Spring框架也是通过一个Bean Factory加载所有的类，那么它是如何加载的？通过IoC模式，也就是依赖性注射模式。在我以前文章“IoC模式”中，我比较了Factory工厂模式创建对象和Ioc模式的注射对象实现之间的异同，Ioc相比工厂模式则更加解耦了调用者和被调用者之间关系，使用Ioc模式，无需在调用者代码中涉及被调用者的具体实现。

　　Spring框架不但可以向自己容器中注射应用者自己定义的JavaBeans（也就是创建它们），而且也可以向这些JavaBeans通过set方法实现数据赋值。

　　一旦Bean Factory运行时刻掌管这些激活的对象，Spring通过AOP方式，从一个横切面为这些JavaBeans提供了权限访问、事务锁等通用功能的实现，这种实现是基于动态代理模式，而动态代理是AOP实现的一种方式。

　　前面提到，Jive中使用代理模式实现权限访问，比代理模式更加简洁和抽象的是动态代理，使用动态代理将使得调用者无需指定被调用者的代理类，这是动态代理区别代理模式的本质。

　　动态代理这一优势，又可以体现在另外一句话语上：动态代理拦截了调用者对被调用者的调用，正是这一功能符合了AOP的拦截器功能，为AOP实现提供了可能。

　　Spring框架使用了动态代理实现的AOP，正是通过动态代理机制拦截了外界对Bean Factory管理下的对象的调用。如下图：

　　以上只是大体解构了Spring的架构，Spring框架在这个架构下，还顺带了很多其它功能，如Web MVC、 DAO JDBC、 DAO ORM 、以及remote，后者类似我设计的EJB方法调用框架。

　　总之，Spring确实是Ioc和AOP的完美应用，Ioc用来装载JavaBeans，创建这些对象；AOP用来拦截这些对象的使用，这才是框架设计的必然经典方式。

Spring Framework从诞生之日起，受到了越来越多的关注。最近，新的开源项目大多支持Spring Framework。国内目前也有专门的网站（http://spring.jactiongroup.net/）。那它为什么如此受欢迎呢？

我想最重要的是，EJB让每个人都痛恨。要编写一个EJB，需要写LocalHome, RemoteHome, Bean, LocalInterface, RemoteInterface，需要一个标准描述符，一个特殊厂商描述符（Weblogic、WebSphere都不一样），如果是Entity Bean，还需要Mapping文件。如此之多，实在麻烦。但EJB最重要的是解决Transaction问题，没有Spring之前，没有其他方法能够描述式的解决它。每个人、每个公司为了解决Transaction的问题，编程的写法都不一样，百花齐放。于是，在最需要它的时候，Spring出现了。

Spring的功能非常多。但对于一个产品，最重要的是如何用好它的精华。Spring包含AOP、ORM、DAO、Context、Web、MVC几个部分组成。Web、MVC暂不用考虑，用成熟的Struts、JSP或Webwork更好。DAO由于目前Hibernate、JDO的流行，也可不考虑。因此最需要用的是AOP、ORM、Context。

Context中，最重要的是Beanfactory，它是将接口与实现分开，非常重要。以前我们写程序，如一个接口IDocument，一个实现类Document1。在写程序时，需写成IDocument doc = new Document1()，一旦我们的实现类需改变时，变为Document2，则程序需写成IDocument doc = new Document2()，所有用到的地方全需改。Beanfactory帮我们解决了这个问题，用context后，写法变为IDocument doc=(IDocument)beanFactory.getBean("doc")。如果实现类从Document1改为Document2，直接在配置文件改就可以了。Context是Bean factory的进一步抽象。很多人都喜欢用ApplicationConext，用Servlet把它Load。这样就把Bean Factory与Web绑定在一起。如果是Fat Client或Remote调用，则这些Bean factory就很难调用，实际是将表现层与业务层绑定的太紧。推荐的方法是SingletonBeanFactoryLocator。具体为：

   BeanFactoryLocator bfLocator = SingletonBeanFactoryLocator.getInstance();
   BeanFactoryReference bf = bfLocator.useBeanFactory("beanFactory");
   // now use some bean from factory
   return bf.getFactory().getBean(name);

 <beans>

     <bean id="beanFactory" class="org.springframework.context.support.ClassPathXmlApplicationContext">
     <constructor-arg>
      <list>
       <value>dataAccessContext.xml</value>
       <value>securityContext.xml</value>
       <value>...</value>
      </list>
     </constructor-arg>
    </bean>

</beans>

这样，就可随时动态扩展，实现组件式的开发。

Spring Framework最得以出名的是与Hibernate的无缝链接，基本上用Spring，就会用Hibernate。可惜的是Spring提供的HibernateTemplate功能显得不够，使用起来也不是很方便。我们编程序时，一般先写BusinessService，由BusinessService调DAO来执行存储，在这方面Spring没有很好的例子，造成真正想用好它，并不容易。

我们的思路是先写一个BaseDao，仿照HibernateTemplate，将基本功能全部实现：

public class BaseDao extends HibernateDaoSupport{

    private Log log = LogFactory.getLog(getClass());

    public Session openSession() {
        return SessionFactoryUtils.getSession(getSessionFactory(), false);
    }

    public Object get(Class entityClass, Serializable id) throws DataAccessException {
        Session session = openSession();
        try {
            return session.get(entityClass, id);
        }
        catch (HibernateException ex) {
            throw SessionFactoryUtils.convertHibernateAccessException(ex);
        }
    }

    public Serializable create(Object entity) throws DataAccessException {
        Session session = openSession();
        try {
            return session.save(entity);
        }
        catch (HibernateException ex) {
            throw SessionFactoryUtils.convertHibernateAccessException(ex);
        }
    }

...

其它的DAO，从BaseDao继承出来，这样写其他的DAO，代码就会很少。

从BaseDao继承出来EntityDao，专门负责一般实体的基本操作，会更方便。

public interface EntityDao {

    public Object get(Class entityClass, Serializable id) throws DataAccessException;

    public Object load(Class entityClass, Serializable id) throws DataAccessException;

    public Serializable create(Object entity) throws DataAccessException;
...}

/**
 * Base class for Hibernate DAOs.  This class defines common CRUD methods for
 * child classes to inherit. User Sping AOP Inteceptor
 */
public class EntityDaoImpl extends BaseDao implements EntityDao{

}

为了Transaction的控制，采用AOP的方式：

public interface EntityManager {

    public Object get(Class entityClass, Serializable id);

    public Object load(Class entityClass, Serializable id);

    public Serializable create(Object entity);
...

}

/**
 * Base class for Entity Service. User Sping AOP Inteceptor
 */
public class EntityManagerImpl implements EntityManager {

    private EntityDao entityDao;

    public void setEntityDao(EntityDao entityDao) {
        this.entityDao = entityDao;
    }

    public Object get(Class entityClass, Serializable id) {
        return entityDao.get(entityClass, id);
    }

    public Object load(Class entityClass, Serializable id) {
        return entityDao.load(entityClass, id);
    }
...

}

这样我们就有了一个通用的Hibernate实体引擎，可以对任何Hibernate实体实现基本的增加、修改、删除、查询等。

其它的BusinessService就可以继承EntityManager，快速实现业务逻辑。

具体XML配置如下：

 <!-- Oracle JNDI DataSource for J2EE environments -->
 <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
  <property name="jndiName"><value>java:comp/env/jdbc/testPool</value></property>
 </bean>

 <!-- Hibernate SessionFactory for Oracle -->
 <!-- Choose the dialect that matches your "dataSource" definition -->
 <bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
  <property name="dataSource"><ref local="dataSource"/></property>
  <property name="mappingResources">
   <value>user-hbm.xml</value>
  </property>
  <property name="hibernateProperties">
   <props>
    <prop key="hibernate.dialect">net.sf.hibernate.dialect.OracleDialect</prop>
    <prop key="hibernate.cache.provider_class">net.sf.ehcache.hibernate.Provider</prop>
    <prop key="hibernate.cache.use_query_cache">true</prop>
                  <prop key="hibernate.show_sql">false</prop>
   </props>
  </property>
 </bean>

 <!-- AOP DAO Intecepter -->
        <bean id="hibernateInterceptor" class="org.springframework.orm.hibernate.HibernateInterceptor">
          <property name="sessionFactory">
            <ref bean="sessionFactory"/>
          </property>
        </bean>

        <bean id="entityDaoTarget" class="com.gpower.services.entity.dao.EntityDaoImpl">
          <property name="sessionFactory">
            <ref bean="sessionFactory"/>
          </property>
        </bean>

        <bean id="entityDao" class="org.springframework.aop.framework.ProxyFactoryBean">
          <property name="proxyInterfaces">
            <value>com.gpower.services.entity.dao.EntityDao</value>
          </property>
          <property name="interceptorNames">
            <list>
              <value>hibernateInterceptor</value>
              <value>entityDaoTarget</value>
            </list>
          </property>
        </bean>

 <!-- Transaction manager for a single Hibernate SessionFactory (alternative to JTA) -->
 <bean id="transactionManager" class="org.springframework.orm.hibernate.HibernateTransactionManager">
  <property name="sessionFactory"><ref local="sessionFactory"/></property>
 </bean>

 <!-- Transaction manager that delegates to JTA (for a transactional JNDI DataSource) -->
 <!--
 <bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>
 -->

 <!-- Transactional proxy for the Application primary business object -->
        <bean id="entityManagerTarget" class="com.gpower.services.entity.EntityManagerImpl">
          <property name="entityDao">
            <ref bean="entityDao"/>
          </property>
        </bean>

        <bean id="entityManager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
          <property name="transactionManager">
            <ref bean="transactionManager"/>
          </property>
          <property name="target">
            <ref bean="entityManagerTarget"/>
          </property>
          <property name="transactionAttributes">
     <props>
       <prop key="get*">PROPAGATION_SUPPORTS</prop>
       <prop key="*">PROPAGATION_REQUIRED</prop>
     </props>
          </property>
        </bean>

资源：Spring+Hibernate培训ppt

以上是关于概念依赖的观念，下面让我们看看如何建模业务中的活动。
有一种做法是使用分析模型中的控制类直接映射到设计中类中。我看来这不是好的做法。
这里谈谈分析与设计的区别。
从分析的角度来看，业务实体总是被动的。业务是通过控制对象操作业务实体来完成的。
分析时我们是关注是什么问题。这要求我们客观的来描述现实。
进入设计阶段我们关注的是如何解决的问题。控制对象施加与业务实体的操作加入不涉及
第三者，则这个操作可以并入被操作的实体类中。然而分析中控制对象的概念是如此的
深刻，以至于只涉及Customer的ChangePassword方法该放到哪里都成了问题。类不是
“某概念 + 所关心该概念的属性 + 最终施加与这些属性上的操作” 的封装，又是什么呢？
下面的问题是如何建模跨越多个业务实体的操作？
举个例子：银行开户。
现在假设开户时涉及到下面的一些操作对象。
创建一个Customer对象。
创建一个CapitalAccount对象。
存入一定数额的现金。
记录一笔开户流水。
整个业务活动，我可以建模为OpenCustomerAct对象。伪码如下：

public class OpenCustomerAct extends CustomerAct
{
...
public void override doRun()
{
Customer customer = Customer.create(...);
CapitalAccount capitalAccount = CapitalAccount.create(customer,...);
capitalAccount.deposit(...);
OpenCustomerLog.create(this);
}
...
}

所需的参数通过构造函数得到。
将所有的业务活动都建模成一个Act，这非常重要。甚至你可以在Session中放入一个Act来
表示当前正在进行的业务。所有的扩展都是从Act开始的。
假如你要对Act施加某种检查，那么对doRun方法进行拦截可以达到该目的。
用例能够简化到只剩下流程，同样道理Act也可以做到这点。
对于象RichClient的交互模式，通常只在最后才提交业务，中间的交互都是在准备提交的数据。
那么在中间调用的方法中可以只new XXXAct而不执行doRun操作。这样做是因为中间的调用
可能会用到XXXAct来作为上下文。现在我还没有想好在这样的中间过程中，如何能够触发
植入到donRun前的检查？或许可以创建一个空doRun的子类覆盖掉父类实际的操作？

Act

public interface Act
{
Operator getOperator();//谁
Date getOccurDate();//在什么时间
String getOccurPlace();//什么地点
BusinessType getBusinessType();//做什么业务
ActState getActState();//业务运行的当前状态
}
“谁在什么时间什么地点做了什么业务。”
这描述了任何业务的基本方面。从哲学的角度来看，“我们得到了Act，我们就得到了事物的基础”。
当我们具体的描述某项业务时，假如需要向调用方暴露特定的属性。
我们可以随时添加到Act的子接口中。
例如同Customer相关的Act可定义为：
public interface CustomerAct extends Act
{
Cutomer getCustomer();//针对哪个客户
}
在复杂一点的情况下，如业务需要多人协作完成，可以通过组合模式达到目的。

public interface CompositeAct extends Act
{
Act[] getActs();
}
涉及到一段时间有中间状态的工作流也应该可以作为Act的子接口进行扩展。
不过我没有做过这方面的尝试。

将Act放入Session

将Act放入Session使得可以方便得到业务运行的上下文。而且通过扩展Act。
可以从Act或其子接口中得到想得到的任何东西,这使得任何扩展都成为可能。

这里说明一下Act类的位置应当放入Potential层中，并且与Operator在一起。
因为Potential层的业务对象也需要业务活动来维护。
如果你的框架中Sesion在更基础的包中，则可以给Act提供一个空内容的父接口,放入Session所在的包中。
public interface AbstractAct
{
}

public interface Act extends AbstractAct
{
...
}
Session提供得到AbstractAct的入口。
public class Session
{
...
static public AbstractAct getAbstractAct()
{
return Instance().abstractAct;
}
...
}

Act上的扩展点

按照分层的观点，下层不允许依赖上层，然而业务对象却是协作完成某个目的的。
而且只要业务对象需要维护，就需要相关的Act。
例如：银行中的存钱业务，参考上面的分层，我们把它放入Operation层。
在存钱的业务中，我们需要检查该客户是否做了挂失。而挂失协议我们是放在Commitment层。
显然，Operation层不能直接调用Commitment层的协议。
DIP模式发话了“用我”。
在Operation层中定义Commitment层接口，和一个工厂，使用反射实现这种调用。在Act中调用。
abstract public class ActImpl
extends abstractActImpl
implements Act
{
public virtual void run()
{
doPreprocess();
doRun();
doPostprocess();
}
abstract public doPreprocess();
abstract public doRun();
abstract public doPostprocess();
}

public interface CustomerCommitment
{
void affirmCanDo();
}

abstract public class CustomerActImpl
extends ActImpl
implements CustomerAct
{
...
public override void doPreprocess()
{
...
//扩展点
CustomerCommitment customerCommitment = CustomerCommitmentFactory.create(this);
customerCommitment.affirmCanDo();
...
}
...
}

public interface InnerCustomerCommitment
{
void affirmCanDo(CustomerAct customerAct);
}

public class CustomerCommitmentImpl implements CustomerCommitment
{
private CustomerAct customerAct;

public CustomerCommitmentImpl(CustomerAct customerAct)
{
this.customerAct = customerAct;
}

public void affirmCanDo()
{
...
//通过配置得到该customerAct对应需要检查的客户约束，包括协议,逐一检查。
DomainObjectCollection commitmentTypes = CustomerCommimentRepository.findByBusinessType(customerAct.getBusinessType());

...
foreach( CommitmentType typeItem in commitmentTypes )
{
InnerCustomerCommitment commitment = getCommitment(typeItem);
commitmentItem.affirmCanDo(customerAct);
}
...
}
}

public class CustomerLostReportAgreementChecker implements InnerCustomerCommitment
{
public void affirmCanDo(CustomerAct customerAct)
{
Check.require(customerAct.getCustomer() != null,"客户不存在");

CustomerLostReportAgreement customerLostReportAgreement =
CustomerLostReportAgreementRepository.find(customerAct.getCustomer());

if(customerLostReportAgreement != null)
{
agreement.affirmCanDo(customerAct);
}

}
}

public class CustomerLostReportAgreement
{
...
public void AffirmCanDo(CustomerAct customerAct)
{
if(customerAct.getOccurDate <= expiringDate)
throw new CustomerLossReportedException(customer);
}
...
}

同样道理，可以对其他上层的对象使用DIP使依赖倒置。
比如：电信计算费用。就可以通过在CustomerAct的doRun中插入扩展点来实现。
这样复杂的计费算法就被封装在接口之后了。可以分配另外的人员来开发。
业务活动的流程仍然清晰可见。
是啊，这正是接口的威力，大多数的设计模式不也是基于这种原理吗？

还有在Act上的扩展点可以分为两类，显式的和隐式的。
电信费用的计算就是显式的，因为CustomerAct需要知道计算的结果，用来从帐户中扣除金额。
而检查挂失协议是隐式的，CustomerAct可以对此一无所知。

通过在Act上的扩展点，我们可以向上扩展。
这仿佛是在树枝上种木耳，呵呵。

DIP VS Facade

对于上面的情况，另外一种方法是使用Facade。
让我们比较一下两者。
简要说明一下Facade的做法：
abstract public class CustomerActImpl
extends ActImpl
implements CustomerAct
{
...
public override void doPreprocess()
{
...
//注意：这里传递的参数，会使得用Facade方式的人大伤脑筋。
//按照挂失的要求目前传递getBusinessType(),getCustomer(),getOccurDate()就够了
//但是对于所有的CustomerCommitment这些参数就不一定够了。
//比如：客户可能签订指定员工协议。（指只允许协议中指明的员工能操作的业务）
//那么该接口需要添加getOperator()参数。
//接口变得不稳定。
CustomerCommitmentManager.affirmCanDo(getBusinessType(),getCustomer(),getOccurDate(),?,...);
...
}
...
}

Facade可以使得在Act中也是只提供一个调用点，但是因为不是依赖倒置的关系，不得不显示的说明需要用到的参数。
相反使用DIP模式，接口中定义的是Act的接口，而Act是可以扩展的。(是否扩展全部看上层的对象是否需要)。
而正是因为相应的CustomerCommitment总是处于需要检查的XXXAct的上层。这样具体的CustomerCommitment
总是可以依赖XXXAct。因此可以获得任何想要得到的信息。

同样对于电信计算费用的例子，因为传递的参数是CustomerAct接口。所以对于今后任何可能的扩展该接口都是不会变化的。
能够做到这一点，完全要归功于将计算费用放入Operation的上层Policy中，你能体会到其中的要领吗？

形象一点来说，使用DIP模式，采取的是一种专家模式。
DIP的Act说的是：“CustomerCommitment你看看我现在的情况，还能运行吗？”
相反Facade模式，则是令人厌烦的唠叨模式。
Facade的Act说的是：“CustomerCommitment，现在执行的客户是XXX,业务是XXX,时间是XXX,...你能告诉我还能运行下去吗？”
显然DIP要潇洒得多。

实现接口　VS　继承父类 　

这里稍稍偏离一下主题，讨论一下接口同继承的问题。
什么时候使用接口？什么时候使用继承？
这似乎是个感觉和经验问题。或者我们会倾向于多使用接口，少使用继承。
可不可以再进一步呢？
以下是我的观点：

“接口是调用方要求的结果，而继承则是实现方思考的产物。”

毕竟如果我们定义的接口没有被用到，那它就没有任何用处。
接口的目的在于制定虚的标准，从而使调用方不依赖于实现方。
而继承某个父类则多半是基于“偷懒“的考虑，已经存在的东西，我为什么不利用一下？
当然这样说是忽略了继承的真正用意－－单点维护。

所以在定义XXXAct的接口时，需要多考虑一下，上层对象需要Act中的提供什么特性，会如何使用它。

接口属于调用方。

业务对象的持久化

一个会引起争议的问题，是业务层是否会涉及业务对象持久化的概念。
答案是肯定的。
DDD中在描述The life cycle of a domain object时，给出了两种形式的持久化。
Store和Archive。我们使用的较多是Store。

但是这不代表业务层要依赖数据访问层。相反依赖关系应该倒过来。数据访问层依赖
业务层。通常我们使用Mapper实现，在hibernate中通过配置达到该目的。
要做到业务层不依赖于数据访问层，同样借助接口来完成。
在业务层定义数据访问的接口，为了方便，可以使用一个类来封装这些操作。

public interface CustomerFinder
{
Customer findByID(ID id);
Customer findByCode(String code);
DomainObjectCollection findByName(String name);
...
}

public class CustomerRepository
{
private static CustomerFinder finder = null;
private static CustomerFinder getFinderInstance()
{
if (finder == null)
{
finder = (CustomerFinder)FinderRegistry.getFinder("CustomerFinder");
}
return finder;
}

public static Customer findByID(ID id)
{
Customer obj = getFinderInstance().findByID(id);
Check.require(obj != null,
"未找到ID为：" + id.toString() +
"对应的 Customer。");
return obj;
}
...
}

在数据访问层实现这些接口。因为是数据访问层依赖业务层，所以你可以采用多种技术来实现，
使用hibernate这样的开源项目，或者手工编写Mapper。

ID id

另外一个有争议的问题是Domain层是否要引入与业务无关的ID来标识不同的对象呢？
我的经验是在业务层引入ID的概念会使很多事情变得方便些。
如：Lazyload。
这是否不属于业务的范畴？是在概念上不属于业务。但在业务上
不是没有对应的概念。
例如：保存客户定购信息的订单，作为标识的就是订单号，这是给人使用的。
在使用电脑后，我们也给对象一个它能理解的统一标识，这就是ID。
另外不要使用业务上的概念作为主键和外键，因为它们本来就不是数据库的概念。
否则，会使得业务概念同数据库的概念混淆起来。

ID的使用通常会选择效率较高的long类型。
不过我们的实现走得更远，我们将其封装为ID对象。

Service层

现在我们向上看看将业务层包裹的服务层。
服务层是架设在应用层和业务层的桥梁，用来封装对业务层的访问，因此
可以把服务层看作中介，充当两个角色：
1.实现应用层接口要求的接口;
2.作为业务层的外观。
服务层的典型调用如下：

public interface CustomerServices
{
void openCustomer(CustomerInfo cutomerInfo);
void customerLostReport(String customerCode,Date expiringDate,String remark);
CutomerBasicInfo getCutomerBasicInfo(String customerCode);
...
}

public class CustomerServicesImpl
extends ServiceFacade
implements CustomerServices
{
...
public void openCustomer(CustomerInfo cutomerInfo)
{
try
{
init();

OpenCustomerAct openCustomerAct =
new OpenCustomerAct(customerInfo.name,
customerInfo.code,
customerInfo.address,
customerInfo.plainpassword
...
);
openCustomerAct.run();

commit();
}
catch(Exception e)
{
throw ExceptionPostprocess(e);
}
}

public void customerLostReport(String customerCode,Date expiringDate,String remark)
{
try
{
Check.require(customerCode != null && customerCode != "",
"无效的客户代码：" + customerCode);
init();

CustomerLostReportAct customerLostReportAct =
new CustomerLostReportAct(customerCode,
expiringDate,
remark);
customerLostReportAct.run();

commit();
}
catch(Exception e)
{
throw ExceptionPostprocess(e);
}
}

public CutomerBasicInfo getCutomerBasicInfo(String customerCode)
{
try
{
Check.require(customerCode != null && customerCode != "",
"无效的客户代码：" + customerCode);
init();
Customer customer = CustomerRepository.findByCode(customerCode);

//这里选择的是在CustomerRepository外抛出CustomerNotFoundException异常,
//另一种方法是在CustomerRepository中抛出CustomerNotFoundException异常。
//因为CustomerRepository在于通过客户代码查找对应的客户。至于是否应该抛出
//异常则交给业务层或服务层来处理。
//这里有很微妙的区别,抛出CustomerNotFoundException应该是谁的职责呢？
//你的想法是什么？
if(customer == null)
throw new CustomerNotFoundException(customerCode);

CutomerBasicInfo cutomerBasicInfo = CutomerBasicInfoAssembler.create(customer);
return cutomerBasicInfo;
}
catch(Exception e)
{
throw ExceptionPostprocess(e);
}
}

...
}

服务层的代码很简单，不是吗？

上面的代码可以通过AOP进一步的简化。使用AOP实现我希望代码象下面这样简单。
public class CustomerServicesImpl
implements CustomerServices
{
...
public void openCustomer(CustomerInfo cutomerInfo)
{
OpenCustomerAct openCustomerAct =
new OpenCustomerAct(customerInfo.name,
customerInfo.code,
customerInfo.address,
customerInfo.plainpassword
...
);
openCustomerAct.run();
}

public void customerLostReport(String customerCode,Date expiringDate,String remark)
{
Check.require(customerCode != null && customerCode != "",
"无效的客户代码：" + customerCode);
CustomerLostReportAct customerLostReportAct =
new CustomerLostReportAct(customerCode,
expiringDate,
remark);
customerLostReportAct.run();
}

public CutomerBasicInfo getCutomerBasicInfo(String customerCode)
{
Customer customer = CustomerRepository.findByCode(customerCode);
if(customer == null)
throw new CustomerNotFoundException(customerCode);

CutomerBasicInfo cutomerBasicInfo = CutomerBasicInfoAssembler.create(customer);
return cutomerBasicInfo;
}

DTO or Not

我认为是否使用DTO取决于项目的大小，开发团队的结构,以及对项目演变预期的评估结果。
不使用DTO而直接使用PO传递到应用层适用于一个人同时负责应用层和业务层的短期简单项目;
一旦采用该模式作为构架，我不知道业务层是否还能叫做面向对象。
原因如下：
1.使用PO承担DTO的职责传递到应用层，迫使PO不能包含业务逻辑，这样业务逻辑会暴露给应用层。
业务逻辑将由类似于XXXManager的类承担，这样看来似乎PO有了更多的复用机会，因为PO只包含getXXX同setXXX类似的属性。
然而这正类似面向过程模式的范例，使用方法操作结构，程序多少又回到了面向过程的方式。
2.将PO直接传递到应用层，迫使应用层依赖于业务层，如果一个人同时负责应用层和业务层那么问题不大；
如果是分别由不同的人开发，将使得应用层开发人员必须了解业务层对象结构的细节，增加了应用层开发人员的知识范围。
同时因为这种耦合，开发的并行受到影响，相互交流增多。
3.此外这也会使得业务层在构建PO时要特别小心，因为需要考虑传递到应用层效率问题，在构建业务层时需要
考虑应用层的需要解决的问题是不是有些奇怪？

有人会抱怨写XXXAssember太麻烦，我的经验是XXXAssembler都很简单。

我们使用手机，会发现大多数手机提供给的接口都是相同的，这包括0-9的数字键，绿色的接听键，红色的挂机键，还有一块显示屏。
无论我是拿到NOkIA,还是MOTO的手机，我都能使用，作为手机使用者我没有必要知道手机界面下的结构，不用关心
使用的是SmartPhone还是Symbian。

确实,应用层将服务层和业务层看作黑箱要比看作白箱好得多。

摘要
这一章节描述了两种用于映射对象间关系的模式：Foreign Key Association和Association Table。注意，1:n关联背后隐藏的问题和Representing Collections in a Relational Database [Bro+96]中描述的问题是一致的。(2002-08-20 12:29:17)

By axing

将对象关联映射到表的模式

这一章节描述了两种用于映射对象间关系的模式：Foreign Key Association和Association Table。注意，1:n关联背后隐藏的问题和Representing Collections in a Relational Database [Bro+96]中描述的问题是一致的。

模式：Foreign Key Association

摘要

该模式展示了如何将对象间的1:n的关系映射到关系型数据库表中。

示例

考虑经典的订单/订单明细（Order / OrderItem）的例子，一张有效的订单将包含0个以上的订单明细。

问题

如何把1:n的关系映射到关系型数据库表中？

约束

参见一般约束

解决方案

在依赖（dependent）对象的表中插入所属（owner）对象的OID。这个OID可以是数据库的关键字或一个Synthetic Object Identity。

结构

结论

1. 读性能：读取一个订单对象将需要一个连接操作或两次读操作。可以在订单对象中加入到订单明细的引用集合。
2. 写性能：该模式将按照1:n的关联写入依赖对象，如果写入操作不写入未改变的对象的话，那么写入的成本依赖于改变的依赖对象的个数。
3. 性能和冗余 VS 维护成本和普通窗体：该映射模式是关系数据库中最常见的模式，因此它和普通的窗体并没有任何的冲突，因此它的维护成本是比较合理的。
4. 所占空间接近于最优－－除了在依赖对象表中需要的外键字段以外。
5. 特殊查询：由于映射是关系数据库应用最为常见的形式，因此特殊的查询也是不难实现的。
6. 应用程序类型：这种映射模式最适合于关系型应用程序。它不适合用于CAD或CASE应用系统中。因为它是基于以外键形式连接关系表的。实现一个关联需要一次的连接操作或两次的数据库访问。基于页面的存储系统，例如OODBMS，能够更快的处理类似的问题。
7. 和旧有系统的集成：因为大多数的旧有系统正式使用这种映射关系的，把1:n的关联转换为对象不会出现任何新的问题。

实现

1. 一般性能：如果性能上出现低效的情况，你可以考虑在对象/关系映射层下面再增加一个关系型数据库访问层，并应用性能改进模式，例如Controlled Redundancy、Denormalization、或Overflow Tables [Kel+97]。这些模式的目的是为了让你在不影响逻辑映射模式的前提下优化物理表模式。
2. 更新性能：当更新订单明细对象（依赖对象）时，你应该只更新那些已经被修改的对象。更新和插入操作都是较为昂贵的操作。
3. 预取依赖对象：在这个例子中，大多数的用例都需要读入所有的依赖对象（如订单明细），你可以使用连接操作来获得所有的数据，并从单个数据库操作的返回值中构建所有者对象和依赖对象：

   
   select * from Order O, OrderItem I
   where O.key = ‘YourOrderKey’ and
   O.key = I.OrderKey

相关模式

在实践中，1:n的关联总是难以和聚合分离开来。因此在研究本模式时也需要同时参考聚合模式Single Table Aggregation和Foreign Key Aggregation。后者和该模式同样的解决方案，只有稍许的不同。

使用外键的备选方案，包括Controlled Redundancy、Denormalization和Overflow Tables [Kel+97]。

该模式和Association Table模式非常相近，后者是用户解决n:m映射的问题。参看Representing Object Relationships as Tables [Bro+96]。

模式Association Table

摘要

该模式展示了怎样把对象间n:m的关系映射到关系型数据库表中。

示例

员工对象和部门对象间存在着n:m的关系。一个员工可以在多个部门中工作，一个部门通常也包含了不只一个的员工。

问题

怎样把n:m的关系映射到关系型数据库？

约束

参见通用约束

解决方案

创建一张单独的表，来存放两种对象类型的关系中的对象标志（或外键）。其它的对象类型到表的映射可以使用另外适当的模式来处理。

结构

结论

这里的结论和Foreign Key Association中是类似的，只是在环境上有些许的不同，因此这里我们就不重复了。

实现

1. 一般性能：如果性能没有达到预期效果，可以考虑使用数据库优化模式，例如Controlled Redundancy、Denormalization、or Overflow Tables [Kel+97]。我们的例子中处理了n:m的关系，这会使关系变得更为复杂。因此可以把它打散，以便于实行数据库优化。
2. 预取对象：如果在上面的例子中，你预先知道大多数的用例都需要读出所有的依赖对象，例如部门中的员工。那就可以使用连接操作获取所有的数据，并从数据集中构建部门对象和员工对象。如：

   select * from DepartmentTable D, EmployeeDepartmentTable ED,EmployeeTable E
   where D.SyntheticOID = ‘YourDepartment’
   D.SyntheticOID = ED.DepartmentKey and
   ED.EmployeeKey = E.SyntheticOID

相关模式

该模式，非常接近于Foreign Key Association。参看Representing Object Relationships as Tables [Bro+96]。

已知应用

Single Table Aggregation, Foreign Key Aggregation, Foreign Key Association, 和Association Table已用于Persistence [www.persistence.com]和TopLink的Smalltalk框架[www.objectpeople.com/toplink/]，以及其它的大多数持久性框架中。这些模式还被用于HYPO-Bank [Col+96,Kel+96]的对象/关系访问层，和POET [POE96]的对象/关系网关。

One Inheritance Tree One Table and One Class One Table曾在POET [POE96]的对象/关系网关被讨论过，同时被提及的还包括One Inheritance Path One Table。后者还被Champs和HYPO的项目中[Col+96, Hah+95, Kel+96]。

Objects in BLOBs曾用在SMRC搜索原型上[Rei+94, Rei+96]。

By axing

继承映射模式

把继承层次映射到关系型数据库表有很多种做法。以下展示的模式是单种的映射方式，在实际中，你可以混合使用不同的映射方式。

以下的讨论没有涉及多重继承。在领域层中很少会遇到有多重继承的情况。大多数多重继承的使用都可以使用协议继承来实现，一个类从虚基类中继承多种协议。协议类很少有需要持久性的，因此我们只讨论简单的继承。

运行实例

我们选用了一个称为合伙人（partner）的系统中的一部分。一个群体（Party）由任何形式的人（person）组成，可以是自然人（natural person）或法人（institution）。客户和员工都是群体。对于员工，我们将之区分为专职员工（SalariedEmployee）和兼职员工（FreelanceEmployee）。见下图：

图中使用的属性比较少，现实中的系统中会有更多的属性，但是我们这里只是列出了可以表示我们所讨论的模式不同之处的属性。因此它们之中都没有涉及到读咱的属性或关系。并且我们假设以上层次中每一个类都不是虚基类，所有的五个类都可以生成实例。

模式: One Inheritance Tree One Table

摘要

该模式展示了一种方法，将一个完整的继承层次映射到单个的数据库表中。

问题

怎样把一个完整的继承层次映射到单个的数据库表中？

约束

除了文章一开始列出的通用约束，还包括了如下的约束：

1. 多态读取、存储空间和写/更新性能的对比：在一个继承层次中，你需要支持这样的查询：在给定的条件下，查找所有匹配的Party对象。结果集还必须是多态的。在该例中，包括Employee、FreelanceEmployee或SalariedEmployee。这种方案虽然能够支持多态查询，但是既浪费空间，也影响了写/更新性能。
2. 数据库的锁模式：有些数据库只是实现了页面锁，这样的话，你就需要注意数据库的流量，不要让一个表中的锁超出了限制的数量而影响性能。如果把过多的类映射到单个表中，很明显，你必须注意流量的问题。
3. 继承层次的深度：某些方案适合于处理扁平性的继承层次，但难于处理纵深的继承层次。
4. 维护负担：把单个的对象的数据跨越多个表来存放，这样的做法可以加快多态读取的速度，但缺点是增加了维护量，一旦对象需要新增或删除属性，模式的发展也需要考虑物理数据模型中数据的重复问题，这极易导致维护的噩梦。其它的维护实例还包括在一个继承层次中插入类和删除类。
5. 用户自定义的查询：如果你希望给用户赋予自定义查询的权利，那么你需要从用户的角度考虑该映射是否能为用户所理解。

解决方案

把继承层次中的所有对象的属性全集对应到数据库的单个表中。每条记录中那些无用的字段使用Null值。

结构

解决方案示例

上例中的表设计如下图：

结论

1. 写/更新性能：One Inheritance Tree One Table允许在单词的数据库操作中对任何基类的任何一个子类读取和写入。
2. 多态读性能：象全部的基类的子类都可以在一张表中找到一样，多态读也很简单。唯一的难点就是为一条选中的记录构造正确的对象类型。处理这种情况的模式有很多，例如Abstract Interface[Col96]。
3. 所占空间：就像你在上面的映射中所描述的，存储对象的属性会浪费一些空间，浪费空间的多少取决于继承层次的深度。层次越深，不同的属性越多，属性的全集就越大，也就越浪费空间。
4. 通过多个表来均衡数据库负载：将过多的类映射到单个表中会导致低性能。可以在如下的数据库行为中发现这些问题的来源：
5. 如果数据库使用页面级锁，一张表上的过量的传输量会大大降低数据库的访问速度。巧妙的安排簇可以抵消部分的开销。如果单个表上的传输量超过限制，性能将继续恶化，甚至引起死锁。
6. 在单个表上太多的锁还会导致锁扩散。锁的数量是关系型数据库系统中锁扩散问题的罪魁祸首。
7. 某些类需要次级索引来提高搜索速度。如果你在一个单独的数据库表中实现了很多类，相应的你也需要在表中加入索引。一张表上过多的索引会使得更新的时候需要同时更新所有的索引，降低了速度。
8. 维护成本：当映射比较直接、比较简单的时候，只要继承的层次不会很多，模式的改进相对也会比较直接和简单。
9. 特殊查询：由于映射和直观，因此一些特殊的查询也会相对较容易。

实现

1. 考虑将所有的对象都映射到单个的表：你可以把所有的对象类型都放在单个表中－－这将导致表上的大传输量。对于小型的应用系统类说，这不失为切实可行且灵活的方法。
2. 空间的浪费：你需要检查关系数据库是否允许空值压缩。如果允许的话，那么这种映射方法无疑将更具吸引力，因为空值也不会浪费空间。类型标识：表中需要插入类型信息。可以在Synthetic Object Identities中包含类型信息。

相关模式

参看Representing Inheritance in a Relational Database [Bro+96]

模式：One Class One Table

摘要

该模式讨论了如何把一个继承层次中各个类映射到不同的数据库表中。

问题

如何把继承层次中的类映射到数据库表中？

约束

参见One Inheritance Tree One Table模式。

解决方案

将每个类的属性放到不同的表中。在每个表中插入一个Synthetic OID，将子类的行和父类所在表的行关联起来。

结构

解决方案示例

将前例中的类映射到数据库后产生五张表－－每个类一张。单个的SalariedEmployee将存储在五张表其中的三张中：

结论

1. 写/更新性能：该模式提供了非常灵活的映射机制，但缺乏一个较好的性能。考虑在上例中读取FreelanceEmployee的一个实例。它将会包括三次的数据库读操作：一次读FreelanceEmployee表， 一次读Employee表，一次读Party表。写同样需要三次操作，并更新一个或多个索引。在读写相关的任务上，这种映射方式相当费资源，这个代价还随着继承层次的增多而增大。
2. 多态读性能：在我们的例子中，FreelanceEmployee的实例分别对应于不同表的Employee实例和Party实例。因此，多态读只需要读取一张表。这是该模式除去节约空间的优点之外吸引人的另一大优点。
3. 所占空间：这种映射几乎有最佳的空间节约性。唯一的容易就是额外的synthetic OID，来连接不同的层级层次。
4. 维护成本：由于这种映射比较直接，也易于了解，模式的改进也相应较为直接、容易。
5. 特殊查询：由于映射需要访问多个表来获取一个对象实例的数据，特殊的查询比较难以组织，尤其是对于无经验的用户。
6. 根表上的重负载：该模式将会导致根对象类型表上的重负载。在该例中，持有FreelanceEmployee表的写入锁的事务将同时持有对Party表和Employee表的写入锁。参看One Inheritance Tree One Table的结论部分对数据库表瓶颈的负面影响的讨论。

实现

1. 虚类：注意虚类也需要映射到单独的表中。
2. 类型标识：从前一个模式的例子中，我们假设Synthetic Object Identity已经包含了类型信息。为了从多态读取查询返回的结果中构建正确的类型，需要了解某些类型信息。

相关模式

参看Representing Inheritance in a Relational Database [Bro+96]。

模式：One Inheritance Path One Table

摘要

该模式显式了一种将继承路径中的所有属性放到单个的数据库表中的方法。

问题

如何把一个继承层次中的所有类映射到数据库的表中？

约束

和One Inheritance Tree One Table模式的约束相同。

解决方案

将每个类的属性映射到不同的表中。并在表中加入该类的父类的所有属性。

结构

解决方案示例

上例中映射的结果将会产生五张表－－每个类一张。SalariedEmployee用其中的一张表就可以表示，SalariedEmployee的映射方法如下：

结论

1. 写/更新性能：映射需要单次的数据库操作来完成对一个对象的读写。
2. 多态读性能：本例中，对所有的Party对象的查询意味着要访问五张表。和One Class One Table模式移机One Inheritance Tree One Table模式比起来是不小的开销。
3. 所占空间：这种映射提供了最佳的空间占用。没有任何的冗余属性，甚至连额外的synthetic OID都没有。
4. 维护成本：产物一个新的子类意味着需要更新所有的多态查询。增加或删除父类的属性将会导致对所有子类的表结构的修改。
5. 特殊查询：由于映射需要访问不只一张表来完成多态搜索，特殊的多态查询对无经验的用户来说难以编写。对叶结点类的查询将会非常的复杂。

实现

1. 虚类：注意虚类不要映射到表。
2. 类型标识：不需要在表中插入类型信息，因为可以通过表的名称来区分对象类型。因为Synthetic Object Identities包含了类型信息，可以考虑减少它的长度来节省部分的空间。

相关模式

参见Representing Inheritance in a Relational Database [Bro+96]。

模式：Objects in BLOBs

摘要

该模式展示了一种使用BLOB，将对象映射到单个数据库表的方法。该模式覆盖了继承、聚合和关联。

问题

怎样把对象映射到关系型数据库？

约束

参见One Inheritance Tree One Table模式。

解决方案

表包括两个字段：一个是synthetic OID，另一个是变长的BLOB，后者囊括了一个对象内的所有数据。使用流把对象的数据存放到BLOB中。

结构

解决方案示例

任何一种的设计方案都和上图相似。

结论

1. 写/更新性能：Objects in BLOBs可以在单次的数据库操作中读取、写入基类的任何子类。注意，在很多RDBMS中，BLOBs都不是最快的访问数据的类型。
2. 多态读：搜索类来获得属性是非常困难的。由于你没有办法访问BLOB的内部结构，因此就需要在数据库中注册函数，以便于访问属性。这种函数的实现可以参考[Loh+91]。定义和维护这些函数也需要付出客观的代价。
3. 特殊查询：由于搜索类中的属性难以实现，因此特殊查询也同样难于表达。还必须要额外的定义函数。
4. 所占空间：如果你的数据库可以实现变长的BLOBs，所占空间就是最小的。
5. 维护成本：数据库模式的演进将会和面向对象数据库一样容易。

实现

1. 相似实现的起源：Objects in BLOBs已用于原型的研究，该原型正尽可能的像OODBMS靠近，只不过它是使用一个关系型数据库作为存储管理。因此该模式的实现机会等于是在一个已存在的存储管理器的基础上实现OODBMS。
2. 表间的数据库负载均衡：把过多的类映射到一个单独的表会造成低性能。具体的讨论可以参见One Inheritance Tree One Table模式的相关章节。
3. 把OODB的特点和关系型数据库相结合：把这个模式同其它类的对象/关系映射相结合是切实可行的。在这个例子中，BLOB存储了复杂的对象的结构，类似于一个项目计划图一样。可以设置其它的字段来存储信息，以供那些访问已结构化的数据的特殊查询使用。（见图3，这种用BLOBs来存储对象的方式已用于SMRC原型研究[Rei+94, Rei+96]。 SMRC中的BLOBs不仅存储单个类的属性，还包含了一个对象网，这个对象网采用流方式存储在BLOBs中。流方式存储在图3中描述）。此外，除了我们上面介绍的纯粹的使用这种方法外，它还允许关系型数据和OODBMS共存。

图3：对象数据和关系型数据的共存。

相关模式

当只使用该模式的时候，这个模式类似于One Inheritance Tree One Table映射，参看Representing Inheritance in a Relational Database [Bro+96]。

摘要
在面向对象建模期间（OOA）最难回答的问题是，何时使用聚合，何时使用关联。性能和灵活性的权衡将会影响到这个问题的答案。你可以使用Single Table Aggregation。这是一种最自然的聚合映射方式。你也可以使用Foreign Key Aggregation，它常常用于处理1:n聚合的映射，我们将在Foreign Key Aggregation的相关章节中讨论它。(2002-08-20 12:28:18)

By axing

聚合映射的模式

在面向对象建模期间（OOA）最难回答的问题是，何时使用聚合，何时使用关联。性能和灵活性的权衡将会影响到这个问题的答案。你可以使用Single Table Aggregation。这是一种最自然的聚合映射方式。你也可以使用Foreign Key Aggregation，它常常用于处理1:n聚合的映射，我们将在Foreign Key Aggregation的相关章节中讨论它。

模式：Single Table Aggregation

摘要：

该模式展示了如何通过把所有的聚合的对象属性集成到单个的表中的方法把聚合映射到一个关系数据模型。

示例：

考虑下列的对象模型：

图1.一个AddressType，为其它的对象所聚合。

问题：

如何将聚合映射到关系表中？

约束：

1. 性能：为了得到最佳的性能，该方案应该在一次的数据库访问中，不用Join操作获取一个对象。数据库访问应该只获取最少的页面，以节省IO带宽。
2. 可维护性：为了获得最佳的可维护性，那些为多个对象所聚合的聚合类型，应该映射到一组表中，而不是分散到物理数据模型的各个点上。在数据模型层次上实行标准化，这样可以使维护简单。
3. 数据库的一致性：聚合意味着被聚合对象的生命周期和需要聚合的对象的生命周期是相互耦合的。这一点需要由数据库或应用程序代码来保证。

解决方案：

把被聚合对象的属性和使用聚合对象的属性放在同一张表中。

结构：

使用聚合的对象被转换为物理数据模型的一张表中，被聚合对象的数据集成到该表中。

解决方法示例：

我们为Customer对象创建Customer表。InvoiceAddress和DeliveryAddress都集成到Customer表中。

图2.将一个被聚合的对象类型映射到使用聚合的对象的数据库表中。

我们使用前缀来区分同类的属性。这有点类似于C++中的命名空间的概念，例如Customer.DeliveryAddress.Street。

结论：

1. 性能：在性能方面，该方案是最佳的，因为只需要访问一张表就能够获取一个带聚合的对象，并读入所有聚合对象。另一方面，由于聚合对象的字段的增多，一次读取将会增大数据库读入的页面数，导致IO带宽的浪费。
2. 可维护性和灵活性：如果聚合的对象类型被多个对象所引用，那么将会降低可维护性，因为每一次对聚合对象类型的修改都会导致对所有引用聚合对象的修改。
3. 数据库的一致性：删除使用聚合的对象时，聚合对象将会自动删除。不需要任何其它的程序或数据库触发器来控制。
4. 特殊查询：类似查询数据库中所有的AddressType对象之类的查询，都会变得很难处理。

实现：

1. 命名规则：需要为聚合的对象的属性考虑前缀或其它的命名规则。在上面的例子中，我们使用属性名称的缩写形式作为前缀。
2. 物理数据库的页面大小：将聚合对象和使用聚合对象放在同一张表中，在一定程度上弥补了由于对象的部分属性存储在另一个数据库页面上的性能损失。这种情况下，读入的是两个页面，而不是一个。

变化：

我们已经讨论了使用聚合对象类型和聚合对象类型之间最简单的1:1关系。Foreign Key Association模式描述了两种对象类型间1:n的关系，Overflow Table则展示了在1:n的关系下避免采用外键的技巧。

相关模式：

Foreign Key Aggregation模式是Single Table Aggregation模式的备选方案。参考Representing Collections in a Relational Database [Bro+96]。当应用到普通的关系型数据库访问层的时候，还可以对比Denormalization [Kel+97]。

参考：

《Mainstream Objects》（Ed Yourdon [You+95] ）在第21章完整的讨论了在建模时期何时使用聚合和关联、以及如何使用它们的问题。

 

聚合映射的模式

在面向对象建模期间（OOA）最难回答的问题是，何时使用聚合，何时使用关联。性能和灵活性的权衡将会影响到这个问题的答案。你可以使用Single Table Aggregation。这是一种最自然的聚合映射方式。你也可以使用Foreign Key Aggregation，它常常用于处理1:n聚合的映射，我们将在Foreign Key Aggregation的相关章节中讨论它。

模式：Single Table Aggregation

摘要：

该模式展示了如何通过把所有的聚合的对象属性集成到单个的表中的方法把聚合映射到一个关系数据模型。

示例：

考虑下列的对象模型：

图1.一个AddressType，为其它的对象所聚合。

问题：

如何将聚合映射到关系表中？

约束：

1. 性能：为了得到最佳的性能，该方案应该在一次的数据库访问中，不用Join操作获取一个对象。数据库访问应该只获取最少的页面，以节省IO带宽。
2. 可维护性：为了获得最佳的可维护性，那些为多个对象所聚合的聚合类型，应该映射到一组表中，而不是分散到物理数据模型的各个点上。在数据模型层次上实行标准化，这样可以使维护简单。
3. 数据库的一致性：聚合意味着被聚合对象的生命周期和需要聚合的对象的生命周期是相互耦合的。这一点需要由数据库或应用程序代码来保证。

解决方案：

把被聚合对象的属性和使用聚合对象的属性放在同一张表中。

结构：

使用聚合的对象被转换为物理数据模型的一张表中，被聚合对象的数据集成到该表中。

解决方法示例：

我们为Customer对象创建Customer表。InvoiceAddress和DeliveryAddress都集成到Customer表中。

图2.将一个被聚合的对象类型映射到使用聚合的对象的数据库表中。

我们使用前缀来区分同类的属性。这有点类似于C++中的命名空间的概念，例如Customer.DeliveryAddress.Street。

结论：

1. 性能：在性能方面，该方案是最佳的，因为只需要访问一张表就能够获取一个带聚合的对象，并读入所有聚合对象。另一方面，由于聚合对象的字段的增多，一次读取将会增大数据库读入的页面数，导致IO带宽的浪费。
2. 可维护性和灵活性：如果聚合的对象类型被多个对象所引用，那么将会降低可维护性，因为每一次对聚合对象类型的修改都会导致对所有引用聚合对象的修改。
3. 数据库的一致性：删除使用聚合的对象时，聚合对象将会自动删除。不需要任何其它的程序或数据库触发器来控制。
4. 特殊查询：类似查询数据库中所有的AddressType对象之类的查询，都会变得很难处理。

实现：

1. 命名规则：需要为聚合的对象的属性考虑前缀或其它的命名规则。在上面的例子中，我们使用属性名称的缩写形式作为前缀。
2. 物理数据库的页面大小：将聚合对象和使用聚合对象放在同一张表中，在一定程度上弥补了由于对象的部分属性存储在另一个数据库页面上的性能损失。这种情况下，读入的是两个页面，而不是一个。

变化：

我们已经讨论了使用聚合对象类型和聚合对象类型之间最简单的1:1关系。Foreign Key Association模式描述了两种对象类型间1:n的关系，Overflow Table则展示了在1:n的关系下避免采用外键的技巧。

相关模式：

Foreign Key Aggregation模式是Single Table Aggregation模式的备选方案。参考Representing Collections in a Relational Database [Bro+96]。当应用到普通的关系型数据库访问层的时候，还可以对比Denormalization [Kel+97]。

参考：

《Mainstream Objects》（Ed Yourdon [You+95] ）在第21章完整的讨论了在建模时期何时使用聚合和关联、以及如何使用它们的问题。

模式：Foreign Key Aggregation

摘要：

该模式显示了如何使用外键将聚合映射到一个关系数据模型中。

环境：

重新考虑Single Table Aggregation模式中的例子（见图1）。假设你需要把AddressType视为单个的对象，并希望获得比Single Table Aggregation更好的可维护性。

问题：

如何将聚合映射到关系表？

约束：

见Single Table Aggregation模式。

解决方案

为聚合类型使用单独的表。在表中插入Synthetic Object Identity，并使用使用聚合对象表中的对象标记做一个外键，连接到聚合对象。

结构：

AggregatingObject（使用聚合对象）映射到一张表，而AggregatedObject（聚合对象）映射到另一张表。聚合对象的表中包含了Synthetic Object Identity。SyntheticOID字段被使用聚合表中的AggregatedObjectsOID外键字段引用。

解决方案示例

我们使用Single Table Aggregation模式中的例子。Customer表中包含了两个外键引用，指向AddressType表。AddressType表包含了Synthetic Object Identity字段，用于连接两张表。

现在从数据库中获取一个客户对象需要三次访问数据库（一次是对Customer表，另两次是对AddressType：InvoiceAddress和DeliveryAddress），这要比Single Table Aggregation中多两次。

如果AddressType表中增加指回Customer表中Synthetic Object Identity字段的回指字段的话，你就可以用连接来减少访问次数。这样做的代价是在取客户属性时同时取回两个地址。

结论：

1. 性能：Foreign Key Aggregation需要连接操作或至少两次的数据库访问，而Single Table Aggregation只需要一次的数据库操作。如果访问聚合对象的概率较小，这个性能还是可以接受的，如果聚合对象总是需要和使用聚合对象一同返回，那么就需要慎重的思考性能问题了。
2. 可维护性：将对象做分解，例如单独存放AddressType，这将使得维护更加容易，并提高映射的灵活性。
3. 数据库的一致性：聚合对象不会随着使用聚合对象的删除而自动删除。为做到这一点，需要编程或使用数据库触发器来实现。
4. 特殊查询：将聚合对象放到单独的表中可以简化对这些对象的查询。

实现

1. 可以考虑使用领域逻辑中的关键字来代替Synthetic Object Identitie。使用领域关键字的缺点是它们无法指回owner对象。
2. 考虑在聚合对象中插入一个指回使用聚合对象的连接。在地址这个例子中，就是在地址表中插入一个字段，来表明AddressType对象的所有者。这个所有者可能是一个员工、一个客户，或是其它需要使用AddressType的对象。双向的关联在查询、一致性检查和其它方面提供了方便。为了得到聚合对象的所有者，你不需要再次搜索使用聚合对象的表。另一方面，返回连接的开销比较昂贵。

相关模式

其备选方案为Single Table Aggregation。Foreign Key Association模式的工作方式和该模式非常接近。见Representing Collections in a Relational Database [Bro+96]。

发信人: barebell (小心), 信区: Java
标 题: Re: ● ● JDBC中文处理：方法与问题
发信站: BBS 水木清华站 (Tue May 19 22:38:19 1998) WWW-POST

现在我们取得的一点小小进展，在转换字符串时不采用default character
encoding，而是直接采用“GBK”或“GB2312”，在情况A和B底下，从DB取数据
都没有问题，但是写中文到DB也采用“GBK”或“GB2312”时，情况B仍是出错的。

发信人: mah (chip), 信区: Java
标 题: 通过jdbc driver获取数据库中文信息揭密
发信站: BBS 水木清华站 (Tue Aug 11 20:42:16 1998) WWW-POST

当我们使用老外公司开发的jdbc第四类driver获取数据库中文信息时，常会出现乱码现象
，如????D.
解决办法1：
使用interface ResultSet的方法getBytes()得到一byte[]，然后由此byte[]数组产生一
新的
String,可获得正确的汉字，但此方法有一定的局限性，在某些driver上可以实现，如
weblogic公司
开发的fastforward产品。另此种方法不规范，根据sun jdbc的标准varchar和var推荐用
getString()
方法来获取。
解决办法2:
使用interface ResultSet的方法getString(),这时我们得到的String一定是乱码，如何
解决，
String temp = result.getString (s);
if (temp != null) {
byte[] b = temp.getBytes ("8859_1");
temp = new String (b);
此时的temp一定是正确的中文，，，，，，此种方法我在sybase公司开发的jconnect4上
实验成功，在fastforward
上也成功。

目录：

1. 设计目标
2. 开发环境
2.1. 选择平台和框架
2.2. 配置服务器
2.3. 编写Ant脚本
3. 系统设计
3.1. 持久层设计
3.1.1. 设计Domain对象
3.1.2. 配置iBatis
3.1.3. 使用DAO模式
3.2. 逻辑层设计
3.3. Web层设计
3.3.1. 使用MVC模式
3.3.2. 实现Skin
4. 附加功能
4.1.1. 实现图片上传
4.1.2. 生成缩略图
4.1.3. 实现RSS
4.1.4. 实现全文搜索
4.1.5. 发送Email
5. 测试
6. 中文支持
7. 总结
8. 源代码下载
9. 相关资源下载
10. 参考
11. 关于作者

设计目标 (目录)

　　Blog（WebLog）在Internet上越来越流行。许多网友都有了自己的Blog，通过Blog展示自己，结识更过的网友。比较著名的Blog平台是基于ASP.net的开源项目.Text。但是它的逻辑全部以存储过程的形式放在数据库中。虽然存储过程能大大提高数据操作的效率，但是存储过程本身是结构化的程序，无法发挥面向对象的威力，也不便于实现代码复用。因此，我决定实现一个基于J2EE体系的多层结构的Blog平台，功能和界面和.Text非常类似，暂命名为Crystal Blog。实现的功能有：发表和编辑文章；多用户支持；全文检索；RSS支持；图片管理；SMTP邮件发送等常见功能。界面如下：

选择平台和框架 (目录)
　　由于使用J2EE平台，我们准备采用WebLogic Server 8.1作为运行平台，使用WebLogic Workshop8.1这个强大的集成化IDE作为开发工具。
　　数据库选择MS SQL Server 2000 SP3，建立一个名为blog的数据库存储所有的用户数据。由于我们并没有针对特定数据库编码，稍后我们会使用其他数据库测试。在系统设计之前，选择一个优秀的框架能大大提高开发效率。Spring是一个轻量级的J2EE框架。它覆盖了从后台数据库的JDBC封装到前台Web框架的几乎所有方?面。并且，Spring的各个模块耦合非常松散，我们既可以用它作为整个应用程序的框架，也可以仅仅使用它的某一个模块。此外，Spring非常强大的集成功能使我们可以轻易地集成Struts编写的Web端，或者使用Hibernate作为后端的O/R Mapping方案。
　　Spring的核心思想便是IoC和AOP，Spring本身是一个轻量级容器，和EJB容器不同，Spring的组件就是普通的Java Bean，这使得单元测试可以不再依赖容器，编写更加容易。Spring负责管理所有的Java Bean组件，同样支持声明式的事务管理。我们只需要编写好Java Bean组件，然后将它们“装配”起来就可以了，组件的初始化和管理均由Spring完成，只需在配置文件中声明即可。这种方式最大的优点是各组件的耦合极为松散，并且无需我们自己实现Singleton模式。
　　由于后台要使用关系数据库存储数据，使用O/R Mapping必不可少。iBatis是又一个类似于Hibernate的O/R Mapping方案，特点是小巧，配置简单，查询灵活，完全符合我们的要求。
　　除了Spring和iBatis，用到的第三方组件还有：用于全文搜索的Lucene引擎，用于文件上传的common-file-upload 1.0，用于输出RSS的RSSLibJ1.0 RC2。
　　由于使用Spring这个轻量级框架，就无需EJB服务器，只需要Web服务器即可。因此，系统可以运行在WebLogic Server，Tomcat和Resin等支持Servlet和JSP的Web服务器上。

系统设计 (目录)
　　很显然，多层结构的J2EE架构能保证系统的灵活性和可扩展性。我们仍然采用表示层/逻辑层/持久层三层设计。

　　整个系统以Spring为基础，持久层采用DAO模式和iBatis O/R Mapping，封装所有数据库操作；中间层是由Spring管理的普通的JavaBean，采用Fa?ade模式；表示层使用Spring提供的MVC框架。由于Spring对其他框架的良好集成，我们采用Velocity作为View。由于Velocity不能调用Java代码，从而强制使用MVC模式而不是在View中嵌入逻辑代码。

配置服务器 (目录)
　　在WebLogic中新建一个Configuration，命名为blog，添加一个数据源，命名为jdbc/blog：

　　整个应用程序的目录结构如下：

crystalblog/
+ doc/ （存放API文档）
+ report/ （存放JUnit测试结果）
+ src/ （存放java源程序）
+ web/ （web目录）
| + manage/ （存放blog管理页）
| + skin/ （存放blog界面页）
| + upload/ （存放用户上传的图片）
| + WEB-INF/
|   + classes/ （存放编译的class文件）
|   + lib/ （存放用到的所有jar文件）
|   + search/ （存放Lucene的index）
|   + c.tld （使用jstl必须的文件）
|   + dispatcher-servlet.xml （Spring配置文件）
|   + web.xml （标准web配置文件）
+ blog.war （打包的可部署应用）
+ build.xml （ant脚本）

编写Ant?脚本 (目录)
　　Ant是一个非常棒的执行批处理任务的工具。使用Ant能使编译、测试、打包、部署和生成文档等一系列任务全自动化，从而大大节省开发时间。
　　首先我们把用到的所有.jar文件放到/web/WEB-INF/lib中，然后编写compile任务，生成的class文件直接放到web/WEB-INF/classes目录下。如果编译成功，就进行单元测试，单元测试的结果以文本文件存放在report目录中。如果测试通过，下一步便是打包成blog.war文件。接着把应用部署到服务器上，直接将web目录的内容复制到%BEA_HOME%/user_projects/domains/blogdomain/applications/blog/目录下即可。如果要在Tomcat上部署，直接将整个web目录复制到%TOMCAT%/webapps/blog/下。
　　最后，如果需要，可以用javadoc生成api文档。

系统设计 (目录)
　　Crystal Blog共分成三层结构：后台数据持久层，采用DAO模式；中间逻辑层，采用Facade模式；前端Web层，采用MVC结构，使用JSP作为视图。以下是Rational Rose的UML图：

配置iBatis (目录)
　　接下来，使用iBatis实现O/R Mapping。首先从http://www.ibatis.com下载iBatis 2.0，将所需的jar文件复制到web/WEB-INF/lib/目录下。iBatis使用XML配置数据库表到Java对象的映射，先编写一个sql-map-config.xml：

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE sqlMapConfig
  PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN"
  "http://www.ibatis.com/dtd/sql-map-config-2.dtd">
<sqlMapConfig>
  <settings cacheModelsEnabled="false" enhancementEnabled="true"
    lazyLoadingEnabled="true" maxRequests="32"
    maxSessions="10" maxTransactions="5"
    useStatementNamespaces="false"
  />
  <transactionManager type="JDBC">
    <dataSource type="JNDI">
      <property name="DataSource" value="jdbc/blog" />
    </dataSource>
  </transactionManager>
  <!-- 如果有其他xml配置文件，可以包含进来 -->
  <sqlMap resource="Account.xml" />
</sqlMapConfig>

　　将sql-map-config.xml放到web/WEB-INF/classes/目录下，iBatis就能搜索到这个配置文件，然后编写一个初始化类：

public class SqlConfig {
    private SqlConfig() {}
    private static final SqlMapClient sqlMap;
    static {
        try {
            java.io.Reader reader = Resources.getResourceAsReader ("sql-map-config.xml");
            sqlMap = SqlMapClientBuilder.buildSqlMapClient(reader);
        } catch (Exception e) {
            e.printStackTrace();
            throw new RuntimeException("Error initializing SqlConfig. Cause: " + e);
        }
    }
    public static SqlMapClient getSqlMapInstance () {
        return sqlMap;
    }
}

　　SqlMapClient封装了访问数据库的大部分操作，可以直接使用SqlConfig.getSqlMapInstance()获得这个唯一实例。

使用DAO模１ 式 (目录)
　　为了分离逻辑层和数据库持久层，定义一系列DAO接口：AccountDao，CategoryDao，ArticleDao……其实现类对应为SqlMapAccountDao，SqlMapCategoryDao，SqlMapArticleDao……这样就使得逻辑层完全脱离了数据库访问代码。如果将来需要使用其它的O/R Mapping方案，直接实现新的DAO接口替代现有的SqlMapXxxDao即可。
　　以SqlMapAccountDao为例，实现一个login()方法是非常简单的：

public int login(String username, String password) throws AuthorizationException {
    try {
        Map map = new HashMap();
        map.put("username", username);
        map.put("password", password);
        Integer I = (Integer)sqlMap.queryForObject("login", map);
        if(I==null)
            throw new RuntimeException("Failed: Invalid username or password.");
        return I.intValue();
    }
    catch(SQLException sqle) {
        throw new RuntimeException("Sql Exception: " + sqle);
    }
}

　　在Account.xml配置文件中定义login查询：

<select id="login" parameterClass="java.util.Map" resultClass="int">
  select [accountId] from [Account] where
  [username] = #username# and password = #password#
</select>

逻辑层设计 (目录)
　　由于DAO模式已经实现了所有的数据库操作，业务逻辑主要是检查输入，调用DAO接口，因此业务逻辑就是一个简单的Facade接口：

public class FacadeImpl implements Facade {
    private AccountDao  accountDao;
    private ArticleDao  articleDao;
    private CategoryDao categoryDao;
    private FeedbackDao feedbackDao;
    private ImageDao    imageDao;
    private LinkDao     linkDao;
    private SequenceDao sequenceDao;
}

　　对于普通的getArticle()等方法，Facade仅仅简单地调用对应的DAO接口：

public Article getArticle(int articleId) throws QueryException {
    return articleDao.getArticle(articleId);
}

　　对于需要身份验证的操作，如deleteArticle()方法，Facade需要首先验证用户身份：

public void deleteArticle(Identity id, int articleId) throws DeleteException {
    Article article = getArticleInfo(articleId);
    if(article.getAccountId()!=id.getAccountId())
        throw new AuthorizationException("Permission denied.");
    articleDao.deleteArticle(articleId);
}

　　要分离用户验证逻辑，可以使用Proxy模式，或者使用Spring的AOP，利用MethodInterceptor实现，不过，由于逻辑很简单，完全可以直接写在一块，不必使用过于复杂的设计。
　　至此，我们的Blog已经实现了所有的后台业务逻辑，并且提供统一的Facade接口。前台Web层仅仅依赖这个Facade接口，这样，Web层和后台耦合非常松散，即使替换整个Web层也非常容易。

Web层设计 (目录)
使用MVC模式 (目录)
　　对于复杂的Web层，使用MVC模式是必不可少的。虽然Spring能轻易集成Struts，WebWorks等Web框架，但Spring本身就提供了一个非常好的Web框架，能完全实现MVC模式。
　　Spring使用一个DispatcherServlet，所有的特定请求都被转发到DispatcherServlet，然后由相应的Controller处理，Controller返回一个ModelAndView对象（因为Java语言的方法调用只能返回一个结果，而且不支持ref参数，所以将Model和View对象合在一起返回），Model是一个Java对象，通常是Map，View是视图的逻辑名字，通常是JSP文件名，但也可以使用Velocity等作为视图。返回的View通过viewResolver得到真正的文件名。
　　首先配置Spring的MVC，在web.xml中声明DispatcherServlet，处理所有以.c结尾的请求：

<web-app>
    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>dispatcher</servlet-name>
        <url-pattern>*.c</url-pattern>
    </servlet-mapping>
</web-app>

　　Spring会在WEB-INF下查找一个名为dispatcher-servlet.xml的文件，我们需要创建这个文件：

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
 "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
</beans>

　用到的所有的Java Bean组件都要在这个文件中声明和配置，以下是配置URL映射的Bean：

<bean id="urlMapping"
 class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="mappings">
        <props>
            <prop key="/article.c">articleController</prop>
        </props>
    </property>
</bean>

　　凡是匹配/article.c的Request都会被名为articleController的Bean处理，同样需要声明这个articleController：

<bean id="articleController" class="example.ViewArticleController">
</bean>

　ViewArticleController处理请求，然后生成Model，并选择一个View：

public class ViewArticleController implements Controller {
    private Facade facade;
    public void setFacade(Facade facade) { this.facade = facade; }
public ModelAndView handleRequest(HttpServletRequest request,
    HttpServletResponse response) throws Exception {
        // 获得参数：
        int articleId = Integer.parseInt(request.getParameter("articleId"));
        // 使用facade处理请求：
        Article article = facade.getArticle(articleId);
        // 生成Model：
        Map map = new HashMap();
        map.put("article", article);
        // 返回Model和视图名“skin/blueskysimple/article”：
        return new ModelAndView("skin/blueskysimple/article", map);
    }
}

　　最后，skin/bluesky/article视图会将结果显示给用户。
　　我们注意到，ViewArticleController并不自己查找或者创建Facade，而是由容器通过setFacade(Facade)方法设置的，这就是所谓的IoC（Inversion of Control）或者Dependency Injection。容器通过配置文件完成所有组件的初始化工作：

<!-- 声明一个Facade -->
<bean id="facade" class="example.Facade" />
<!-- 声明一个Controller -->
<bean id="articleController" class="example.ViewArticleController">
    <!-- 为articleController设置facade属性 -->
<property name="facade">
        <!-- 将名为facade的Bean的引用传进去 -->
        <ref bean="facade" />
    </property>
</bean>

　　以上配置文件实现的功能大致为：

Facade facade = new Facade();
ViewArticleController articleController = new ViewArticleController();
articleController.setFacade(facade);

　　但是我们不必编写以上代码，只需在xml文件中装配好我们的组件就可以了。所有组件由Spring管理，并且，缺省的创建模式是Singleton，确保了一个组件只有一个实例。
　　此外，所有自定义异常都是RuntimeException，Spring提供的AOP使我们能非常方便地实现异常处理。在Web层定义ExceptionHandler，处理所有异常并以统一的error页面把出错信息显示给用户，因此，在代码中只需抛出异常，完全不必在Controller中处理异常：

<bean id="handlerExceptionResolver" class="org.crystalblog.web.ExceptionHandler" />

使用Velocity作为View
　　采用Velocity作为View的最大的优点是简洁，能通过简单明了的语法直接在Html中输出Java变量。Velocity本身是一个模板引擎，通过它来渲染Model输出Html非常简单，比如显示用户名：

<b>${account.username}</b>
　　换成JSP不得不写成：
<b><%=account.getUsername()%></b>
而<%...%>标记在Dreamwaver中无法直接看到其含义。如果需要在标签中嵌入JSP就更晦涩了：
<a href="somelink?id=<%=id %>">Link</a>

　　这种嵌套的标签往往使得可视化Html编辑器难以正常显示，而Velocity用直接嵌入的语法解决了“ <%...%>”的问题。
　　在Spring中集成Velocity是非常简单的事情，甚至比单独使用Velocity更简单，只需在dispatcher-servlet.xml中申明：

<bean id="viewResolver" class="org.springframework.web.servlet.view.velocity.VelocityViewResolver">
</bean>
<bean id="velocityConfig" class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
    <property name="resourceLoaderPath"><value>/</value></property>
    <property name="configLocation"><value>/WEB-INF/velocity.properties</value></property>
</bean>

　　虽然标准的Velocity模板以.vm命名，但我们的所有Velocity模板页均以.html作为扩展名，不但用Dreamwaver编辑极为方便，甚至可以直接用IE观看页面效果。

实现Skin (目录)
　　许多Blog系统都允许用户选择自己喜欢的界面风格。要实现Skin功能非常简单，为每个Skin编写Velocity模板，存放在web/skin/目录下，然后在Controller中返回对应的视图：

String viewpath = skin.getSkin(account.getSkinId()) + "viewArticle";

　　由于使用了MVC模式，我们已经为每个页面定义好了Model，添加一个新的skin非常容易，只需要编写几个必须的.html文件即可，可以参考现有的skin。
　　SkinManager的作用是在启动时自动搜索/skin/目录下的所有子目录并管理这些skin，将用户设定的skinId映射到对应的目录。目前只有一个skin，您可以直接用可视化Html编辑器如Dreamwaver改造这个skin。

附加功能 (目录)
实现图片上传 (目录)
　　用户必须能够上传图片，因此需要文件上传的功能。比较常见的文件上传组件有Commons FileUpload（http://jakarta.apache.org/commons/fileupload/a>）和COS FileUpload（http://www.servlets.com/cos），Spring已经完全集成了这两种组件，这里我们选择Commons FileUpload。
　　由于Post一个包含文件上传的Form会以multipart/form-data请求发送给服务器，必须明确告诉DispatcherServlet如何处理MultipartRequest。首先在dispatcher-servlet.xml中声明一个MultipartResolver：

<bean id="multipartResolver"
       class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
        <!-- 设置上传文件的最大尺寸为1MB -->
        <property name="maxUploadSize">
        <value>1048576</value>
    </property>
</bean>

　　这样一旦某个Request是一个MultipartRequest，它就会首先被MultipartResolver处理，然后再转发相应的Controller。
　　在UploadImageController中，将HttpServletRequest转型为MultipartHttpServletRequest，就能非常方便地得到文件名和文件内容：

public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
    // 转型为MultipartHttpRequest：
    MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request;
    // 获得文件：
    MultipartFile file = multipartRequest.getFile("file");
    // 获得文件名：
    String filename = file.getOriginalFilename();
    // 获得输入流：
    InputStream input = file.getInputStream();
    // 写入文件...
}

生成缩略图 (目录)
　　当用户上传了图片后，必须生成缩略图以便用户能快速浏览。我们不需借助第三方软件，JDK标准库就包含了图像处理的API。我们把一张图片按比例缩放到120X120大小，以下是关键代码：

public static void createPreviewImage(String srcFile, String destFile) {
    try {
        File fi = new File(srcFile); // src
        File fo = new File(destFile); // dest
        BufferedImage bis = ImageIO.read(fi);

        int w = bis.getWidth();
        int h = bis.getHeight();
        double scale = (double)w/h;
        int nw = IMAGE_SIZE; // final int IMAGE_SIZE = 120;
        int nh = (nw * h) / w;
        if( nh>IMAGE_SIZE ) {
            nh = IMAGE_SIZE;
            nw = (nh * w) / h;
        }
        double sx = (double)nw / w;
        double sy = (double)nh / h;

        transform.setToScale(sx,sy);
        AffineTransformOp ato = new AffineTransformOp(transform, null);
        BufferedImage bid = new BufferedImage(nw, nh, BufferedImage.TYPE_3BYTE_BGR);
        ato.filter(bis,bid);
        ImageIO.write(bid, "jpeg", fo);
    } catch(Exception e) {
        e.printStackTrace();
        throw new RuntimeException("Failed in create preview image. Error: " + e.getMessage());
    }
}

实现RSS (目录)
　　RSS是一个标准的XML文件，Rss阅读器可以读取这个XML文件获得文章的信息，使用户可以通过Rss阅读器而非浏览器阅读Blog，我们只要动态生成这个XML文件便可以了。RSSLibJ是一个专门读取和生成RSS的小巧实用的Java库，大小仅25k，可以从http://sourceforge.net/projects/rsslibj/下载rsslibj-1_0RC2.jar和它需要的EXMLjar两个文件，然后复制到web/WEB-INF/lib/下。
　　使用RSSLibJ异常简单，我们先设置好HttpServletResponse的Header，然后通过RSSLibJ输出XML即可：

Channel channel = new Channel();
channel.setDescription(account.getDescription());
baseUrl = baseUrl.substring(0, n);
channel.setLink("http://server-name/home.c?accountId=" + accountId);
channel.setTitle(account.getTitle());
List articles = facade.getArticles(accountId, account.getMaxPerPage(), 1);
Iterator it = articles.iterator();
while(it.hasNext()) {
    Article article = (Article)it.next();
    channel.addItem("http://server-name/article.c?articleId=" + article.getArticleId(),
        article.getSummary(), article.getTitle()
    );
}
// 输出xml:
response.setContentType("text/xml");
PrintWriter pw = response.getWriter();
pw.print(channel.getFeed("rss"));
pw.close();

实现全文搜索 (目录)
　　全文搜索能大大方便用户快速找到他们希望的文章，为blog增加一个全文搜索功能是非常必要的。然而，全文搜索不等于SQL的LIKE语句，因为关系数据库的设计并不是为全文搜索设计的，数据库索引对全文搜索无效，在一个几百万条记录中检索LIKE ＇%A%＇可能会耗时几分钟，这是不可接受的。幸运的是，我们能使用免费并且开源的纯Java实现的Lucene全文搜索引擎，Lucene可以非常容易地集成到我们的blog中。
　　Lucene不提供直接对文件，数据库的索引，只提供一个高性能的引擎，但接口却出人意料地简单。我们只需要关心以下几个简单的接口：
　　Document：代表Lucene数据库的一条记录，也代表搜索的一条结果。
　　Field：一个Document包含一个或多个Field，类似关系数据库的字段。
　　IndexWriter：用于创建新的索引，也就是向数据库添加新的可搜索的大段字符串。
　　Analyzer：将字符串拆分成单词（Token），不同的文本对应不同的Analyzer，如HtmlAnalyzer，PDFAnalyzer。
　　Query：封装一个查询，用于解析用户输入。例如，将“bea blog”解析为“同时包含bea和blog的文章”。
　　Searcher：搜索一个Query，结果将以Hits返回。
　　Hits：封装一个搜索结果，包含Document集合，能非常容易地输出结果。
　　下一步，我们需要为Article表的content字段建立全文索引。首先为Lucene新建一个数据库，请注意这个数据库是Lucene专用的，我们不能也不必知道它的内部结构。Lucene的每个数据库对应一个目录，只需要指定目录即可：

String indexDir = "C:/search/blog";
IndexWriter indexWriter = new IndexWriter(indexDir, new StandardAnalyzer(), true);
indexWriter.close();

　　然后添加文章，让Lucene对其索引：

String title = "文章标题" // 从数据库读取
String content = "文章内容" // 从数据库读取
// 打开索引：
IndexWriter indexWriter = new IndexWriter(indexDir, new StandardAnalyzer(), false);
// 添加一个新记录：
Document doc = new Document();
doc.add(Field.Keyword("title", title));
doc.add(Field.Text("content", content));
// 建立索引：
indexWriter.addDocument(doc);
// 关闭：
indexWriter.close();

　要搜索文章非常简单：
　然后添加文章，让对其索引：

String title = "文章标题" // 从数据库读取
String content = "文章内容" // 从数据库读取
// 打开索引：
IndexWriter indexWriter = new IndexWriter(indexDir, new StandardAnalyzer(), false);
// 添加一个新记录：
Document doc = new Document();
doc.add(Field.Keyword("title", title));
doc.add(Field.Text("content", content));
// 建立索引：
indexWriter.addDocument(doc);
// 关闭：
indexWriter.close();

　　要搜索文章非常简单：

Searcher searcher = new IndexSearcher(dir);
Query query = QueryParser.parse(keyword, "content", new StandardAnalyzer());
Hits hits = searcher.search(query);
if(hits != null){
    for(int i = 0;i < hits.length(); i++){
        Document doc = hits.doc(i);
        System.out.println("found in " + doc.get("title"));
        System.out.println(doc.get("content"));
    }
}
searcher.close();

　　我们设计一个LuceneSearcher类封装全文搜索功能，由于必须锁定数据库所在目录，我们把数据库设定在/WEB-INF/search/下，确保用户不能访问，并且在配置文件中初始化目录：

<bean id="luceneSearcher" class="org.crystalblog.search.LuceneSearcher">
    <property name="directory">
       <value>/WEB-INF/search/</value>
    </property>
</bean>

效果如下：

（图4：search）

发送Email (目录)
　　Blog用户可以让系统将来访用户的留言发送到注册的Email地址，为了避免使用SMTP发信服务器，我们自己手动编写一个SendMail组件，直接通过SMTP协议将Email发送到用户信箱。
　　SendMail组件只需配置好DNS服务器的IP地址，即可向指定的Email信箱发送邮件。并且，SendMail使用缓冲队列和多线程在后台发送Email，不会中断正常的Web服务。具体代码请看SendMail.java。

测试 (目录)
　　服务器配置为：P4 1.4G，512M DDR，100M Ethernet，Windows XP Professional SP2。
　　测试服务器分别为WebLogic Server 8.1，Tomcat 4.1/5.0，Resin 2.1.1。
　　测试数据库为MS SQL Server 2000 SP3。如果你使用Oracle或者DB2，MySQL等其他数据库并测试成功，请将SQL初始化脚本和详细配置过程发一份给我，谢谢。
　　由于时间有限，没有作进一步的调优。WebLogic Server和iBatis有很多优化选项，详细配置可以参考相关文档。

中文支持 (目录)
　　测试发现，中文不能在页面中正常显示，为了支持中文，首先在web.xml加入Filter，用于将输入编码设置为gb2312：

<filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.crystalblog.web.filter.EncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>gb2312</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

　　然后用文本工具搜索所有的.htm，.html，.properties文件，将“iso-8859-1”替换为“gb2312”，现在页面中文已经能正常显示，但是Lucene仍不能正常解析中文，原因是标准的StandardA?nalyzer只能解析英文，可以从网上下载一个支持中文的Analyzer。

总结 (目录)
　　Spring的确是一个优秀的J2EE框架，通过Spring强大的集成和配置能力，我们能轻松设计出灵活的多层J2EE应用而无需复杂的EJB组件支持。由于时间仓促，水平有限，文中难免有不少错误，恳请读者指正。

源代码下载 (目录)
　　源代码可以从http://www.javasprite.com/crystal/download.asp下载。

相关资源下载 (目录)
JDK 1.4.2可以从http://java.sun.com下载。
Spring framework 1.1可以从http://www.springframework.org下载。
iBatis 2.0可以从http://www.ibatis.com下载。
Tomcat 4.1/5.0、Ant 1.6可以从http://www.apache.org下载。
Resin 2.1.1可以从http://www.caucho.com下载。
WebLogic Server / Workshop 8.1可以从http://commerce.bea.com下载。
JUnit 3.8可以从http://www.junit.org下载。
MySQL 4及其JDBC驱动可以从http://www.mysql.com下载。
MS SQL Server 2000 JDBC驱动可以从http://www.microsoft.com/downloads/details.aspx?FamilyID=07287b11-0502-461a-b138-2aa54bfdc03a&DisplayLang=en下载。
RSSLibJ 1.0可以从http://sourceforge.net/projects/rsslibj/下载。

参考 (目录)
“Spring Reference”，Rod Johnson等。
“iBatis SQL Maps Guide”。
“Apache Ant 1.6.2 Manual”。
“Lucene Getting Started”。
Springframework的JPetStore示例是非常棒的设计，本文参考了JPetStore的许多设计模式。

关于作者
廖雪峰，北京邮电大学本科毕业，对J2EE/J2ME有浓厚兴趣，欢迎交流：asklxf@163.com。
个人网站：http://www.javasprite.com，欢迎访问。
个人Blog站点：http://blog.csdn.net/asklxf/，欢迎访问。

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd"> <struts-config> <form-beans> <form-bean name="dynamicArrayForm" type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="people" type="demo.Person[]"/> </form-bean> </form-beans> <action-mappings> <action path="/setupForm" type="demo.SetupFormAction" name="dynamicArrayForm" scope="session" validate="false"> <forward name="success" path="/displayForm.jsp"/> </action> <action path="/processActorComments" type="demo.ProcessFormAction" name="dynamicArrayForm" scope="session" validate="false"> <forward name="success" path="/displayForm.jsp"/> </action> </action-mappings> </struts-config>

package demo; /** * Copyright 2004, James M. Turner. * All Rights Reserved * * A Struts action that sets up a DynaForm which is globally scoped */ import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.*; import org.apache.struts.action.*; import org.apache.struts.validator.DynaValidatorForm; public class SetupFormAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { DynaValidatorForm df = (DynaValidatorForm) form; Person[] p = new Person[3]; p[0] = new Person(); p[0].setDateOfBirth("07/13/1942"); p[0].setLastName("Ford"); p[0].setFirstName("Harrison"); p[0].setGender("M"); p[1] = new Person(); p[1].setDateOfBirth("10/21/1956"); p[1].setLastName("Fisher"); p[1].setFirstName("Carrie"); p[1].setGender("F"); p[2] = new Person(); p[2].setDateOfBirth("09/25/1951"); p[2].setLastName("Hamill"); p[2].setFirstName("Mark"); p[2].setGender("M"); df.set("people", p); return mapping.findForward("success"); } }

<!-- Copyright 2004, James M Turner. All Rights Reserved --> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %> <%@ taglib uri="/WEB-INF/c.tld" prefix="c" %> <head> <title>Star Wars Actor Fact Page</title> </head> <H1><center>Start Wars Actor Fact Page</title> <html:form action="/processActorComments" > <table border="1" width="80%"> <tr><th>Last Name</th><th>First Name</th><th>Date of Birth</th><th>Comment</th></tr> <c:forEach var="people" items="${dynamicArrayForm.map.people}"> <tr><td><c:out value="${people.lastName}"/></td> <td><c:out value="${people.firstName}"/></td> <td><c:out value="${people.dateOfBirth}"/></td> <td><html:text name="people" indexed="true" property="comment"/></td> </tr> </c:forEach> </table> <P/> <html:submit value="Update Comments"/> </html:form>

package demo; /** * Copyright 2004, James M. Turner. * All Rights Reserved * * A Struts action that sends the new comments to the console */ import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.*; import org.apache.struts.action.*; import org.apache.struts.validator.DynaValidatorForm; public class ProcessFormAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { DynaValidatorForm df = (DynaValidatorForm) form; Person[] p = (Person[]) df.get("people"); for (int i = 0; i < p.length; i++) { System.out.println(p[i].getFirstName() + " " + p[i]. getLastName() + ":" + p[i].getComment()); } return mapping.findForward("success"); } }

Harrison Ford:Indiana Jones Carrie Fisher:Postcards from the Edge Mark Hamill:Wing Commander

<form-bean name="dynamicHashmapForm" type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="people" type="java.util.HashMap"/> <form-property name="comments" type="java.util.HashMap"/> </form-bean>

package demo; /** * Copyright 2004, James M. Turner. * All Rights Reserved * * A Struts action that sets up a DynaForm which is globally scoped */ import java.io.IOException; import java.util.HashMap; import javax.servlet.ServletException; import javax.servlet.http.*; import org.apache.struts.action.*; import org.apache.struts.validator.DynaValidatorForm; public class SetupHashFormAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { DynaValidatorForm df = (DynaValidatorForm) form; HashMap hm = (HashMap) df.get("people"); Person p = new Person(); p = new Person(); p.setDateOfBirth("07/13/1942"); p.setLastName("Ford"); p.setFirstName("Harrison"); p.setGender("M"); hm.put("1", p); p = new Person(); p.setDateOfBirth("10/21/1956"); p.setLastName("Fisher"); p.setFirstName("Carrie"); p.setGender("F"); hm.put("2", p); p = new Person(); p.setDateOfBirth("09/25/1951"); p.setLastName("Hamill"); p.setFirstName("Mark"); p.setGender("M"); hm.put("3", p); return mapping.findForward("success"); } }

<!-- Copyright 2004, James M Turner. All Rights Reserved --> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %> <%@ taglib uri="/WEB-INF/struts-html-el.tld" prefix="html-el" %> <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %> <%@ taglib uri="/WEB-INF/c.tld" prefix="c" %> <%@ taglib prefix="fmt" uri="/WEB-INF/fmt.tld" %> <head> <title>Star Wars Actor Fact Page</title> </head> <H1><center>Start Wars Actor Fact Page</title> <html:form action="/processHashActorComments" > <table border="1" width="80%"> <tr><th>Last Name</th><th>First Name</th> <th>Date of Birth</th><th>Comment</th></tr> <c:forEach var="people" items="${dynamicHashmapForm.map.people}"> <tr><td><c:out value="${people.value.lastName}"/></td> <td><c:out value="${people.value.firstName}"/></td> <td><c:out value="${people.value.dateOfBirth}"/></td> <td><html-el:text property="comments(${people.value.lastName}, ${people.value.firstName})" /></td> </tr> </c:forEach> </table> <P/> <html:submit value="Update Comments"/> </html:form>

package demo; /** * Copyright 2004, James M. Turner. * All Rights Reserved * * A Struts action that sends the new comments to the console */ import java.io.IOException; import java.util.HashMap; import java.util.Iterator; import javax.servlet.ServletException; import javax.servlet.http.*; import org.apache.struts.action.*; import org.apache.struts.validator.DynaValidatorForm; public class ProcessHashFormAction extends Action { public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { DynaValidatorForm df = (DynaValidatorForm) form; HashMap hm = (HashMap) df.get("comments"); Iterator it = hm.keySet().iterator(); while (it.hasNext()) { String key = (String) it.next(); String comment = (String) hm.get(key); System.out.println(key + ":" + comment); } return mapping.findForward("success"); } }

同样，这里最大的差别是数据都是作为HashMaps 来存储的。代码获取关键字(lastname,firstname)，然后显示关键字和在控制台注释:

Fisher,Carrie:Leia
Ford,Harrison:Han
Hamill,Mark:Luke

请注意，当控制返回到JSP页时，打印一个空白表格。这是因为我们在初始化操作中创建的HashMap 已经没有了，在处理结果时我们不能重新创建它。你可以将该数据保存在会话期变量中，但是接着你要返回到你使用第一个方案的地方。最好是选择一个关键字，在表格提交时它可以允许你在后台对象上获得，并且能够总是重新创建需要的任何其他的表格数据。
哪种方式更好？基于排列的方案允许你将所有的数据都保存在一个bean 内，而基于堆栈的方法避免了任何会话期范围的数据。你觉得哪种方案最好就采用哪种。
注意：包含运行这些例子所需的所有代码和库的WAR 文件在http://www.blackbear.com/struts.war.上可以找到。


关于作者:James Turner 是Benefit Systems有限公司软件开发总监。他对Apache Struts 项目颇有贡献。他已经出版了两本面向WEB的JAVA技术的书：MySQL and JSP Web Applications, 和Struts Kick Start。他的第三本书，Java Server Faces Kick Start，在2003年冬季由Sams出版发行