Spring 的微内核与FactoryBean扩展机制--转载

作者：江南白衣 原文地址：
http://www.blogjava.net/calvin/archive/2005/08/30/11099.html http://www.blogjava.net/calvin/archive/2005/08/26/11243.html
DreamHead在《思考微内核》十分激赏 Spring的微内核与扩展机制：
“Spring的微内核在哪里呢？便是DI容器。而通过FactoryBean，我们可以定制自己的组件组装过程，对一个普通的JavaBean做手脚，像Spring AOP中常用的ProxyFactoryBean做的那样。如此，我们就不必把所有功能都做到Spring的DI容器中去，而是以一个FactoryBean来对DI容器的功能进行扩展。除了Spring自身之外，现在已经有一些项目开始利用这个特性扩展Spring，比如，Acegi Security和Spring Modules。”

 这确是框架容器界应该贯彻的范式，微内核提供最少的功能，而由扩展接口去增强框架的能力。下面看看Spring怎么设计，明白之后就可以开始为Spring捐献精力了:)

1、微内核的功能
1.1 DI(依赖注入)与Singleton管理

      利用POJO setter的DI机制，估计每位同学随手都能写一个简单版本，不多说了。

      Singleton管理说白了就是先到一个map中按id找找看有没有已存在的实例。

1.2 BeanName与BeanFactory注入

      除了DI注入的属性，微内核还有什么能卖给POJO呢？就是Bean在xml 定义里的id和BeanFactory自己了。

      卖的机制是让POJO 实现 BeanNameAware和BeanFactoryAware接口。BeanFactory用 if(pojo instance of BeanFactoryAware)判断到POJO需要注入BeanFactory,就调用setBeanFactory(this)将自己注入。

      这种框架中基于接口的注入和调用机制在Java下挺标准的，Spring的功能多是基于这种模式提供。遗憾就是Java不支持多重继承，作为替代的接口里不能提供默认的实现，导致每一个Pojo都要很无聊的实现一遍setBeanFactory()。

1.3 DI后的初始化函数调用

      比如属性A,B注入之后，需要同时根据A和B来对A,B进行加工或者装配一个内部属性C，这样就需要在所有属性注入后再跑一个init()函数。

      Spring提供两种方式，一种是和上面的原理一样，实现InitializingBean接口的afterPropertiesSet()函数供Spring调用。

      一种是在xml定义文件里面自行定义init函数名。

      懒得每次在xml文件里定义的就采用第1种方式，不想与spring耦合的pojo就采用第2种方式。本来就是为了扩展Spring而存在的FactoryBean多采用第一种。

   所谓微内核，就是仅提供以上三种功能的DI容器。

   但作为轻量级容器，还需要以下两种方式，向容器内的POJO 附加各种服务。

2.FactoryBean扩展机制

Spring的AOP、ORM、事务管理、JMX、Quartz、Remoting、Freemarker、Velocity，都靠FacotryBean的扩展，FacotryBean几乎遍布地上：

<bean id="sessionFactory"

class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"/>

<bean id="baseDAOService"

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"/>

只不过当年对这类factoryBean比较麻木不仁，不问原理的照搬照用了。

不过这原理说出来也好简单，所有FactoryBean 实现FactoryBean接口的getObject()函数。Spring容器getBean(id)时见到bean的定义是普通class时，就会构造该class的实例来获得bean，而如果发现是FacotryBean接口的实例时，就通过调用它的getObject()函数来获得bean，仅此而以.......可见，很重要的思想，可以用很简单的设计来实现。

考察一个典型的FactoryBean：
    一般会有两个变量，三个接口：

    一个setter函数注入需要改装的pojo，一个内部变量保持装配后的对象returnOjbect。

    implements三个接口 ：FactoryBean,InitializingBean和BeanFactoryAware 。

    各接口的意义之前都讲过了。factoryBean会在afterPropertiesSet()里把pojo改装成returnObject，需要用到beanfactory进行天马行空的动作时就靠BeanFactoryAware注入。最后在getObject()里把returnObject返回。

Rod说：IoC principles, combined with the factory bean, afford a powerful means to abstract the act of obtaining or accessing services and resources

3. Bean Post-Processor扩展机制

     如果说FactoryBean 是一种Factory、Wrapper式的扩展，Bean Post-Processor就是另一种AOP、visitor式的机制，所以也多用于spring的AOP架构。

      Post-Processor的原理就是BeanFactory在前文里的调用afterPropertiesSet()/init-method前后，调用在工厂里注册了的post-processor的postProcessBeforeInitialization()和postProcessAfterInitialization()。

      那怎么注册登记呢？又分请不请礼仪公司两类。如果是ApplicationContext，你把继承BeanPostProcessor 的bean往xml里一搁就行了,application context自会打理。如果是BeanFacotry，就要显式的注册，代码大概像：

     

XmlBeanFactory factory = new XmlBeanFactory("C:/beans.xml"); 

BeanPostLogger logger = new BeanPostLogger(); 

factory.addBeanPostProcessor(logger);

Rod说："Post-processors add the ability to customize bean and container behavior in a flexible, externalized fashion. "

对比Factory Bean那段，可见两种机制在他心目中的不同作用。

 

扩展Spring(2) ---Spring对各种数据访问框架的集成机制

     何为数据框架集成。
   数据访问框架原本好好的，Spring都干了什么呢？

   一是用template类封装了数据框架那些资源获取和异常事务处理的废话代码，而且按照自己的意见给出一些增强函数。

   二是将其纳入了Spring的声明式事务管理中。

    对比Spring对Hibernate、JDBC的集成，还有Spring Modules对O/R Broker的集成，发现Spring的DAO框架主要有六个类：

    1.Template 

      著名的Template类，用callback机制封装了除业务代码外的所有必要但废话的代码，重新封装了数据框架的API，并再附送一些增强版。

    2.TransactionManager 
      实现PlatformTransactionManager接口，数据访问框架就能与Spring的事务机制(TransactionTemplate或AOP声明式事务)结合。

    重要的类仅以上两个，以下的类都只有少量标准代码，完全可以忽略。

    3.DAOSupport
       实际DAO类的基类，负责保持template变量。如果你觉得它破坏了你的类层次结构，完全可以不用。

    4.Accessor
     template类的基类，defining common properties like DataSource and exception translator，也没大用。

    5.Operations
     template所实现的接口，定义template支持的数据访问函数和增强函数，template有多个实现时才有用。

    6.Exception Translate的相关类和函数
     异常翻译，Spring DAO很重视的一个功能。

Template类的代码
   因为Hibernate本身很复杂，所以HibernateTemplate也不适合畏高晕车的人士如我观看。JDBC简单很多，但JDBCTemplate又忙着增强JDBC的功能，多出好多代码。所以我选O/R broker的集成代码来看，代码一共才280行。

注：如果不熟O/R broker，可以简单的认为broker=connection, executable = statement ，其余一切同Jdbc。

1.1主干函数 Execute(BrokerCallback action)

      step1. 获得Connection-- connecton = datasource.getConn();

      step2. 准备Statement -- statement = new Statement(connection);

      step3. 执行Action的回调函数doInBroker(Statement)。这个doInBroker()方法由客户定义，会拿着传入的statement，执行种种操作。

              

 try

{

  action.doInBroker(statement );

}

catch()

{

   //翻译异常

}

   1.2 template的API函数

         虽然理论上大家可以直接使用execute()，在匿名内部类里调用数据访问框架的任何API。但java的匿名内部类不比闭包，代码难看无比，所以除了Robbin还没见到其他兄弟提倡直接用execute方法的。

        因此，template也对数据框架的API进行了wrap，封装了用execute(StatementCallback action)来执行这些API的函数，如下段就是wrap 了O/R Broker的execute(String statementID.....)方法：

public int execute(final String statementID, final String[] paramNames, final Object[] values) throws DataAccessException {

    return executeWithIntResult(new BrokerCallback() {

      public Object doInBroker(Executable executable) throws BrokerException {

        applyNamedParamsToExecutable(executable, paramNames, values);

        return new Integer(executable.execute(statementID));

      }

    });

  }

    另外还提供一些增强型、便利型的API(如selectOne() ,selectMany())，在参数、返回值上极尽变化。

TransactionManager的代码
   比较复杂，一下说不清。但JDBC的DatasourceTransactionManager和Hibernate的HibernateTransactionManager的代码都很相近，说明这个TransactionManager其实也比较固定埋头狂抄就是了。

    有兴趣的同学，可以响应某大老号召，实现ofbiz与spring的集成:)