Spring探秘之如何妙用BeanPostProcessor
前言
最近,在給項目組使用Spring搭建Java項目基礎框架時,發(fā)現使用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容器所創(chuàng)建的每個bean實例在初始化方法(如afterPropertiesSet和任意已聲明的init方法)調用前,將會調用BeanPostProcessor中的postProcessBeforeInitialization方法,而在bean實例初始化方法調用完成后,則會調用BeanPostProcessor中的postProcessAfterInitialization方法,整個調用順序可以簡單示意如下:
--> Spring IOC容器實例化Bean
--> 調用BeanPostProcessor的postProcessBeforeInitialization方法
--> 調用bean實例的初始化方法
--> 調用BeanPostProcessor的postProcessAfterInitialization方法
可以看到,Spring容器通過BeanPostProcessor給了我們一個機會對Spring管理的bean進行再加工。比如:我們可以修改bean的屬性,可以給bean生成一個動態(tài)代理實例等等。一些Spring AOP的底層處理也是通過實現BeanPostProcessor來執(zhí)行代理包裝邏輯的。
BeanPostProcessor實戰(zhàn)
了解了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();
}
}
}
可以看到,這樣的代碼看起來十分不優(yōu)雅,并且如果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{
/**
* 在配置系統(tǒng)中開關的屬性名稱,應用系統(tǒng)將會實時讀取配置系統(tǒng)中對應開關的值來決定是調用哪個版本
* @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();
}
}
現在我們可以停下來對比一下封裝前后調用代碼了,是不是感覺改造后的代碼優(yōu)雅很多呢?那么這是怎么實現的呢,我們一起來揭開它的神秘面紗吧,請看代碼:
@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注解的屬性,如果發(fā)現存在該注解則給該屬性注入一個動態(tài)代理類實例
- RoutingBeanProxyFactory類功能就是生成一個代理類實例,代理類的邏輯也比較簡單。版本路由支持到方法級別,即優(yōu)先檢查方法是否存在路由配置RoutingSwitch,方法不存在配置時才默認使用類路由配置
好了,BeanPostProcessor的介紹就到這里了。不知道看過后大家有沒有得到一些啟發(fā)呢?
總結
到此這篇關于Spring探秘之如何妙用BeanPostProcessor的文章就介紹到這了,更多相關Spring妙用BeanPostProcessor內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
- Spring BeanPostProcessor接口使用詳解
- Spring中的后置處理器BeanPostProcessor詳解
- SpringBoot之通過BeanPostProcessor動態(tài)注入ID生成器案例詳解
- Spring BeanPostProcessor(后置處理器)的用法
- Spring?BeanPostProcessor后處理器源碼解析
- 詳解使用Spring的BeanPostProcessor優(yōu)雅的實現工廠模式
- Spring源碼解析之BeanPostProcessor知識總結
- Spring BeanPostProcessor源碼示例解析
- Spring注解驅動之BeanPostProcessor后置處理器講解
- Spring組件初始化擴展點:BeanPostProcessor
相關文章
Java如何用一個統(tǒng)一結構接收成員名稱不固定的數據
這篇文章主要為大家詳細介紹了Java如何用一個統(tǒng)一結構接收成員名稱不固定的數據,文中的示例代碼講解詳細,感興趣的小伙伴可以跟隨小編一起學習一下2024-11-11

