Spring探秘之如何妙用BeanPostProcessor

目录
  • 前言
  • BeanPostProcessor简介
  • BeanPostProcessor实战
  • 总结

前言

最近,在给项目组使用Spring搭建Java项目基础框架时,发现使用Spring提供的BeanPostProcessor可以很简单方便地解决很多看起来有点难解决的问题。本文将会通过一个真实案例来阐述BeanPostProcessor的用法

BeanPostProcessor简介

BeanPostProcessor是Spring IOC容器给我们提供的一个扩展接口。接口声明如下:

public interface BeanPostProcessor {
    //bean初始化方法调用前被调用
    Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
    //bean初始化方法调用后被调用
    Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;

}

如上接口声明所示,BeanPostProcessor接口有两个回调方法。当一个BeanPostProcessor的实现类注册到Spring IOC容器后,对于该Spring IOC容器所创建的每个bean实例在初始化方法(如afterPropertiesSet和任意已声明的init方法)调用前,将会调用BeanPostProcessor中的postProcessBeforeInitialization方法,而在bean实例初始化方法调用完成后,则会调用BeanPostProcessor中的postProcessAfterInitialization方法,整个调用顺序可以简单示意如下:

--> Spring IOC容器实例化Bean
--> 调用BeanPostProcessor的postProcessBeforeInitialization方法
--> 调用bean实例的初始化方法
--> 调用BeanPostProcessor的postProcessAfterInitialization方法

可以看到,Spring容器通过BeanPostProcessor给了我们一个机会对Spring管理的bean进行再加工。比如:我们可以修改bean的属性,可以给bean生成一个动态代理实例等等。一些Spring AOP的底层处理也是通过实现BeanPostProcessor来执行代理包装逻辑的。

BeanPostProcessor实战

了解了BeanPostProcessor的相关知识后,下面我们来通过项目中的一个具体例子来体验一下它的神奇功效吧。

先介绍一下我们的项目背景吧:我们项目中经常会涉及AB 测试,这就会遇到同一套接口会存在两种不同实现。实验版本与对照版本需要在运行时同时存在。下面用一些简单的类来做一个示意:

public class HelloService{
     void sayHello();
     void sayHi();
}

HelloService有以下两个版本的实现:

@Service
public class HelloServiceImplV1 implements HelloService{
     public void sayHello(){
          System.out.println("Hello from V1");
     }
     public void sayHi(){
          System.out.println("Hi from V1");
     }
}
@Service
public class HelloServiceImplV2 implements HelloService{
     public void sayHello(){
          System.out.println("Hello from V2");
     }
     public void sayHi(){
          System.out.println("Hi from V2");
     }
}

做AB测试的话,在使用BeanPostProcessor封装前,我们的调用代码大概是像下面这样子的:

@Controller
public class HelloController{
     @Autowird
     private HelloServiceImplV1 helloServiceImplV1;
     @Autowird
     private HelloServiceImplV2 helloServiceImplV2;

     public void sayHello(){
          if(getHelloVersion()=="A"){
               helloServiceImplV1.sayHello();
          }else{
               helloServiceImplV2.sayHello();
          }
     }
     public void sayHi(){
          if(getHiVersion()=="A"){
               helloServiceImplV1.sayHi();
          }else{
               helloServiceImplV2.sayHi();
          }
     }
}

可以看到,这样的代码看起来十分不优雅,并且如果AB测试的功能点很多的话,那项目中就会充斥着大量的这种重复性分支判断,看到代码就想死有木有!!!维护代码也将会是个噩梦。比如某个功能点AB测试完毕,需要把全部功能切换到V2版本,V1版本不再需要维护,那么处理方式有两种:

  • 把A版本代码留着不管:这将会导致到处都是垃圾代码从而造成代码臃肿难以维护
  • 找到所有V1版本被调用的地方然后把相关分支删掉:这很容易在处理代码的时候删错代码从而造成生产事故。

怎么解决这个问题呢,我们先看代码,后文再给出解释:

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface RoutingInjected{
}
@Target({ElementType.FIELD,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface RoutingSwitch{
    /**
     * 在配置系统中开关的属性名称,应用系统将会实时读取配置系统中对应开关的值来决定是调用哪个版本
     * @return
     */
     String value() default "";
}
@RoutingSwitch("hello.switch")
public class HelloService{

    @RoutingSwitch("A")
    void sayHello();

    void sayHi();
}
@Controller
public class HelloController{

    @RoutingInjected
    private HelloService helloService;

    public void sayHello(){
        this.helloService.sayHello();
    }

    public void sayHi(){
        this.helloService.sayHi();
    }
}

现在我们可以停下来对比一下封装前后调用代码了,是不是感觉改造后的代码优雅很多呢?那么这是怎么实现的呢,我们一起来揭开它的神秘面纱吧,请看代码:

@Component
public class RoutingBeanPostProcessor implements BeanPostProcessor {

    @Autowired
    private ApplicationContext applicationContext;

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        Class clazz = bean.getClass();
        Field[] fields = clazz.getDeclaredFields();
        for (Field f : fields) {
            if (f.isAnnotationPresent(RoutingInjected.class)) {
                if (!f.getType().isInterface()) {
                    throw new BeanCreationException("RoutingInjected field must be declared as an interface:" + f.getName()
                                    + " @Class " + clazz.getName());
                }
                try {
                    this.handleRoutingInjected(f, bean, f.getType());
                } catch (IllegalAccessException e) {
                    throw new BeanCreationException("Exception thrown when handleAutowiredRouting", e);
                }
            }
        }
        return bean;
    }

    private void handleRoutingInjected(Field field, Object bean, Class type) throws IllegalAccessException {
        Map<String, Object> candidates = this.applicationContext.getBeansOfType(type);
        field.setAccessible(true);
        if (candidates.size() == 1) {
            field.set(bean, candidates.values().iterator().next());
        } else if (candidates.size() == 2) {
            Object proxy = RoutingBeanProxyFactory.createProxy(type, candidates);
            field.set(bean, proxy);
        } else {
            throw new IllegalArgumentException("Find more than 2 beans for type: " + type);
        }
    }
}
public class RoutingBeanProxyFactory {

    public static Object createProxy(Class targetClass, Map<String, Object> beans) {
        ProxyFactory proxyFactory = new ProxyFactory();
        proxyFactory.setInterfaces(targetClass);
        proxyFactory.addAdvice(new VersionRoutingMethodInterceptor(targetClass, beans));
        return proxyFactory.getProxy();
    }
    static class VersionRoutingMethodInterceptor implements MethodInterceptor {
        private String classSwitch;
        private Object beanOfSwitchOn;
        private Object beanOfSwitchOff;

        public VersionRoutingMethodInterceptor(Class targetClass, Map<String, Object> beans) {
            String interfaceName = StringUtils.uncapitalize(targetClass.getSimpleName());
            if(targetClass.isAnnotationPresent(RoutingSwitch.class)){
                this.classSwitch =((RoutingSwitch)targetClass.getAnnotation(RoutingSwitch.class)).value();
            }
            this.beanOfSwitchOn = beans.get(this.buildBeanName(interfaceName, true));
            this.beanOfSwitchOff = beans.get(this.buildBeanName(interfaceName, false));
        }

        private String buildBeanName(String interfaceName, boolean isSwitchOn) {
            return interfaceName + "Impl" + (isSwitchOn ? "V2" : "V1");
        }

        @Override
        public Object invoke(MethodInvocation invocation) throws Throwable {
            Method method = invocation.getMethod();
            String switchName = this.classSwitch;
            if (method.isAnnotationPresent(RoutingSwitch.class)) {
                switchName = method.getAnnotation(RoutingSwitch.class).value();
            }
            if (StringUtils.isBlank(switchName)) {
                throw new IllegalStateException("RoutingSwitch's value is blank, method:" + method.getName());
            }
            return invocation.getMethod().invoke(getTargetBean(switchName), invocation.getArguments());
        }

        public Object getTargetBean(String switchName) {
            boolean switchOn;
            if (RoutingVersion.A.equals(switchName)) {
                switchOn = false;
            } else if (RoutingVersion.B.equals(switchName)) {
                switchOn = true;
            } else {
                switchOn = FunctionSwitch.isSwitchOpened(switchName);
            }
            return switchOn ? beanOfSwitchOn : beanOfSwitchOff;
        }
    }
}

我简要解释一下思路:

  • 首先自定义了两个注解:RoutingInjected、RoutingSwitch,前者的作用类似于我们常用的Autowired,声明了该注解的属性将会被注入一个路由代理类实例;后者的作用则是一个配置开关,声明了控制路由的开关属性
  • 在RoutingBeanPostProcessor类中,我们在postProcessAfterInitialization方法中通过检查bean中是否存在声明了RoutingInjected注解的属性,如果发现存在该注解则给该属性注入一个动态代理类实例
  • RoutingBeanProxyFactory类功能就是生成一个代理类实例,代理类的逻辑也比较简单。版本路由支持到方法级别,即优先检查方法是否存在路由配置RoutingSwitch,方法不存在配置时才默认使用类路由配置

好了,BeanPostProcessor的介绍就到这里了。不知道看过后大家有没有得到一些启发呢?

总结

到此这篇关于Spring探秘之如何妙用BeanPostProcessor的文章就介绍到这了,更多相关Spring妙用BeanPostProcessor内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • SpringBoot如何读取xml配置bean(@ImportResource)

    目录 读取xml配置bean(@ImportResource) 1.应用场景 2.spring-common.xml 3.SpringBoot读取xml 4.应用xml中的bean对象 5.Service类 6.测试 读取配置文件中的参数 1.打开eclipse开发工具软件 2.在项目中确保pom.xml文件已引用 3.在项目中的src/main/resource文件录目下 4.在application.properties配置文件中添加对应的参数 5.此时在项目启动的时候 6.在需要使用的配置

  • Spring Bean Scope 有状态的Bean与无状态的Bean

    有状态会话bean:每个用户有自己特有的一个实例,在用户的生存期内,bean保持了用户的信息,即“有状态”:一旦用户灭亡(调用结束或实例结束),bean的生命期也告结束.即每个用户最初都会得到一个初始的bean.         无状态会话bean:bean一旦实例化就被加进会话池中,各个用户都可以共用.即使用户已经消亡,bean   的生命期也不一定结束,它可能依然存在于会话池中,供其他用户调用.由于没有特定的用户,那么也就不能保持某一用户的状态,所以叫无状态bean.但无状态会话bean  

  • spring Bean创建的完整过程记录

    目录 前言 bean创建的流程图 快速开始 总结 前言 复习一下spring实现IOC的源码流程准备工作: ​强烈建议大家从git上拉取spring源码来学习Spring源码.因为里面相较于IDEA生成的会有注释,里面有的方法会有注释看起来会省力一点. ​以下都是用5.0.2版本来做阐述. bean创建的流程图 写在前面:建议大家一定要自己用实例跑一遍,做好记录.如果只是看看会非常抽象.此流程图作为梗概,便于加强记忆和理解,新手或无基础的有个印象即可.等跟随本文走通一遍,在回过头看这个图,或许会

  • Spring bean配置单例或多例模式方式

    目录 Spring bean配置单例或多例模式 单例 多例 Spring scope配置单例.多例模式 1.scope属性介绍 2.scope配置 3.单例模式底层实现模拟 Spring bean配置单例或多例模式 单例 spring bean 默认是单例默认,在对应.xml文件中的配置是: <bean id="user" class="..." scope="singleton"/> singleton就是配置这个bean是否是单例

  • Spring @bean和@component注解区别

    目录 Spring 中的一些注解 2. Autowire 和 @Resource 的区别 3. 将一个类声明为 Spring 的 bean 的注解有哪些? 4. @Configuration :配置类注解 5. @ControllerAdvice :处理全局异常利器 6. @Component, @Repository, @Service 的区别 总结 本文打算介绍几个不太容易说出其区别,或者用途的 Spring 注解,比如 @Component 与 @Bean 的比较,@ControllerA

  • Spring探秘之如何妙用BeanPostProcessor

    目录 前言 BeanPostProcessor简介 BeanPostProcessor实战 总结 前言 最近,在给项目组使用Spring搭建Java项目基础框架时,发现使用Spring提供的BeanPostProcessor可以很简单方便地解决很多看起来有点难解决的问题.本文将会通过一个真实案例来阐述BeanPostProcessor的用法 BeanPostProcessor简介 BeanPostProcessor是Spring IOC容器给我们提供的一个扩展接口.接口声明如下: public

  • Spring中的后置处理器BeanPostProcessor详解

    BeanPostProcessor接口作用: 如果我们想在Spring容器中完成bean实例化.配置以及其他初始化方法前后要添加一些自己逻辑处理.我们需要定义一个或多个BeanPostProcessor接口实现类,然后注册到Spring IoC容器中. package com.test.spring; import org.springframework.beans.BeansException; import org.springframework.beans.factory.config.B

  • 详解Spring中Bean后置处理器(BeanPostProcessor)的使用

    目录 一.BeanPostProcessor接口 二.案例 三.总结 一.BeanPostProcessor接口 Bean后置处理:对Spring 工厂创建的对象进行二次加工处理,即预初始化和后初始化. PostProcessor中文意思就是后置处理器. BeanPostProcessor 接口也被称为Bean后置处理器,通过该接口可以自定义调用初始化前后执行的操作方法. 该接口中包含了两个方法:before方法(预初始化)和after方法(后厨是化) postProcessBeforeInit

  • spring mvc中注解@ModelAttribute的妙用分享

    前言 本文主要给大家介绍了关于spring mvc注解@ModelAttribute妙用的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 在Spring mvc中,注解@ModelAttribute是一个非常常用的注解,其功能主要在两方面: 运用在参数上,会将客户端传递过来的参数按名称注入到指定对象中,并且会将这个对象自动加入ModelMap中,便于View层使用: 运用在方法上,会在每一个@RequestMapping标注的方法前执行,如果有返回值,则自动将该返回值

  • Spring BeanPostProcessor(后置处理器)的用法

    目录 BeanPostProcessor 一.自定义后置处理器演示 二.多个后置处理器 三.显示指定顺序 对BeanPostProcessor接口的理解 为了弄清楚Spring框架,我们需要分别弄清楚相关核心接口的作用,本文来介绍下BeanPostProcessor接口 BeanPostProcessor 该接口我们也叫后置处理器,作用是在Bean对象在实例化和依赖注入完毕后,在显示调用初始化方法的前后添加我们自己的逻辑.注意是Bean实例化完毕后及依赖注入完成后触发的.接口的源码如下 publ

  • 关于Spring BeanPostProcessor的执行顺序

    目录 Spring BeanPostProcessor执行顺序 Spring-BeanPostProcessor接口总结 定义 BeanPostProcessor BeanPostProcessor总结 InstantiationAwareBeanPostProcessor InstantiationAwareBeanPostProcessor总结 SmartInstantiationAwareBeanPostProcessor SmartInstantiationAwareBeanPostPr

  • Spring Annotaion Support详细介绍及简单实例

    最近正在看spring官网,看Spring IOC的时候看Spring容器扩展点的时候发现了BeanPostProcessor 这个接口.下面是官方对它的详细描述: BeanPostProcessor接口定义了回调方法,您可以实现提供自己的(或覆盖容器的默认)实例化逻辑,依赖性解析逻辑,等等.如果你想实现一些自定义逻辑Spring容器实例化完成后,配置和初始化一个bean,您可以插入一个或多个BeanPostProcessor实现. 您可以配置多个BeanPostProcessor实例,您可以控

  • 详解Spring IOC 容器启动流程分析

    使用 Spring 时,XML 和注解是使用得最多的两种配置方式,虽然是两种完全不同的配置方式,但对于 IOC 容器来说,两种方式的不同主要是在 BeanDefinition 的解析上.而对于核心的容器启动流程,仍然是一致的. AbstractApplicationContext 的 refresh 方法实现了 IOC 容器启动的主要逻辑,启动流程中的关键步骤在源码中也可以对应到独立的方法.接下来以  AbstractApplicationContext 的实现类  ClassPathXmlAp

  • Spring IoC学习之ApplicationContext中refresh过程详解

    refresh() 该方法是 Spring Bean 加载的核心,它是 ClassPathXmlApplicationContext 的父类 AbstractApplicationContext 的一个方法 , 顾名思义,用于刷新整个Spring 上下文信息,定义了整个 Spring 上下文加载的流程. public void refresh() throws BeansException, IllegalStateException { synchronized(this.startupShu

  • Spring源码学习之动态代理实现流程

    注:这里不阐述Spring和AOP的一些基本概念和用法,直接进入正题. 流程   Spring所管理的对象大体会经过确定实例化对象类型.推断构造方法创建对象(实例化).设置属性.初始化等等步骤.在对象初始化阶段,Spring为开发者提供了一个BeanPostProcessor接口,它会在对象初始化之前和初始化之后被调用(初始化,不是实例化,对应实例化的是InstantiationAwareBeanPostProcessor接口). public interface BeanPostProcess

随机推荐