前言
前几天一个工程中,需要实现这样一个场景:根据前端发送过来的请求参数的不同,走不同的 service(可同事走多个),最初我的思路是尝试实现在 spring 中实现动态的依赖注入,也就是根据请求参数,动态的在 controller 中注入某个 service 接口的特定实现(接口有多个实现),但是发现这个实现不了,然后想了想,换了个思路,重新设计了一下,实现了需求中的场景。
正文
我的解决办法是,使用“生产线工人工作能力自己掂量机制”来解决,这名字我自己起的,实际上就是想要实现按参数选择走哪个 service 实现,可以一次性把所有 service 实现全都注入进来,然后依次请求,同时在每个 service 实现中写一套规则判别方法,判断当前请求自己是不是能够处理,如果能够处理,则进入处理方法,若自己没有处理能力,则退出,让请求走到其他 service 做同样的判断。形象点,可以想象一下,在一条生产线的传送带上传送着不同品类的待加工的元部件,有若干工人排列在传送带旁边,每个工人只会加工某一种元件,那么,当传送带上的元件传送到自己面前时,需要判断一下,自己有没有处理这个元件的能力(掂量一下自己的能力),若有,取过来处理,若没有,放过去让别人走流程。
理解了其中逻辑,我们就来看代码吧(片段):
1 |
|
1 |
|
这里有一点需要解释一下,在上面第二段代码中,有这么一段:
1 | @Resource(name = "serviceProviders") |
这里是使用 spring 中的 FactoryBean
机制实现的,可以简单的这样理解 FactoryBean
:FactoryBean
是生成普通 Bean 的 Bean,当注入 FactoryBean
时,默认注入的是其生产出来的所有普通 Bean,而不是它自己。
在上边代码中,注入的名为 serviceProviders 的这个 Bean,实际上是这样定义出来的:
1 | "serviceProviders") // 注意这个 Bean 的名字,当其他 Bean 中注入这个 Bean 时,会注入 createInstance() 返回类型的 Bean,而不是其自身的类型 ServiceProviderFactoryBean ( |
通过这样的设计,就完成了我们的需求,实际上我们等于把思路反转了一下,从想尽办法控制注入到不做控制,一股脑全部注入进去,然后按规则过滤。有时候,其实遇到一条思路走不通的时候,可以反过来想想,也许就会走通。
勘误
「后端圈」小伙伴指出,我这个注入一系列 Beans 的机制写复杂了,实际上在 Spring 中,注入 List<SomeBean> somebeans
就能自动实现将所有 SomeBean
全部注入进来了。压根不需要自己写 FactoryBean
的,这个机制的实现过程,可以参考 Spring 源码:org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveMultipleBeans
和 org.springframework.beans.factory.support.DefaultListableBeanFactory#addCandidateEntry
1 | // 单个Bean的类型为org.springframework.beans.factory.config.DependencyDescriptor,而List<Bean>的类型为org.springframework.beans.factory.support.DefaultListableBeanFactory.MultiElementDescriptor,从这里分成了两个流程 |
1 |
|