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几乎遍布地上:

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

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的集成:)

转载于:https://www.cnblogs.com/davidwang456/p/4462108.html

你可能感兴趣的:(Spring 的微内核与FactoryBean扩展机制--转载)