内容简介：前几天一个工程中，需要实现这样一个场景：根据前端发送过来的请求参数的不同，走不同的 service（可同事走多个），最初我的思路是尝试实现在 spring 中实现动态的依赖注入，也就是根据请求参数，动态的在 controller 中注入某个 service 接口的特定实现（接口有多个实现），但是发现这个实现不了，然后想了想，换了个思路，重新设计了一下，实现了需求中的场景。我的解决办法是，使用“生产线工人工作能力自己掂量机制”来解决，这名字我自己起的，实际上就是想要实现按参数选择走哪个 service 实现
前几天一个工程中，需要实现这样一个场景：根据前端发送过来的请求参数的不同，走不同的 service（可同事走多个），最初我的思路是尝试实现在 spring 中实现动态的依赖注入，也就是根据请求参数，动态的在 controller 中注入某个 service 接口的特定实现（接口有多个实现），但是发现这个实现不了，然后想了想，换了个思路，重新设计了一下，实现了需求中的场景。
正文
我的解决办法是，使用“生产线工人工作能力自己掂量机制”来解决，这名字我自己起的，实际上就是想要实现按参数选择走哪个 service 实现，可以一次性把所有 service 实现全都注入进来，然后依次请求，同时在每个 service 实现中写一套规则判别方法，判断当前请求自己是不是能够处理，如果能够处理，则进入处理方法，若自己没有处理能力，则退出，让请求走到其他 service 做同样的判断。形象点，可以想象一下，在一条生产线的传送带上传送着不同品类的待加工的元部件，有若干工人排列在传送带旁边，每个工人只会加工某一种元件，那么，当传送带上的元件传送到自己面前时，需要判断一下，自己有没有处理这个元件的能力（掂量一下自己的能力），若有，取过来处理，若没有，放过去让别人走流程。
理解了其中逻辑，我们就来看代码吧（片段）：
public interface ServiceProvider {
// 掂量一下自己有没有能力加工当前的元件（也就是Request），能就返回 true 不能返回 false
boolean support(Request request);
// 具体加工元件的逻辑
Response execute(Request request);
}
@Service
public class ServiceImpl implements Service {
// 注入一系列 service 数量不定 https://stackoverflow.com/questions/2153298/how-to-autowire-factorybean
@Resource(name = "serviceProviders")
private List<ServiceProvider> serviceProviders;
@Override
public List<Response> execute(Request request) {
return serviceProviders // 循环每个 service TODO 现在时间复杂度为 O(n) 可以尝试优化为 O(logn)
.stream()
.filter(serviceProvider -> serviceProvider.support(request)) // 按加工能力过滤
.map(serviceProvider -> serviceProvider.execute(request)) // 执行 service 得 execute 方法
.collect(Collectors.toList());
}
}
这里有一点需要解释一下，在上面第二段代码中，有这么一段：
@Resource(name = "serviceProviders") private List<ServiceProvider> serviceProviders;
这里是使用 spring 中的 FactoryBean
机制实现的，可以简单的这样理解 FactoryBean
： FactoryBean
是生成普通 Bean 的 Bean，当注入 FactoryBean
时，默认注入的是其生产出来的所有普通 Bean，而不是它自己。
在上边代码中，注入的名为 serviceProviders 的这个 Bean，实际上是这样定义出来的：
@Component("serviceProviders") // 注意这个 Bean 的名字，当其他 Bean 中注入这个 Bean 时，会注入 createInstance() 返回类型的 Bean，而不是其自身的类型 ServiceProviderFactoryBean
public class ServiceProviderFactoryBean extends AbstractFactoryBean<List<ServiceProvider>> implements ApplicationContextAware {
private ApplicationContext applicationContext;
@Override
public Class<?> getObjectType() {
return List.class;
}
@Override
protected List<ServiceProvider> createInstance() {
// 扫描所有 provider 并从 Bean 容器取出放入 list
Reflections reflections = new Reflections(ServiceProvider.class.getPackage().getName());
return reflections
.getSubTypesOf(ServiceProvider.class)
.stream()
.map((Function<Class<? extends ServiceProvider>, ServiceProvider>) serviceProviderClass -> applicationContext.getBean(serviceProviderClass))
.collect(Collectors.toList());
}
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
}
通过这样的设计，就完成了我们的需求，实际上我们等于把思路反转了一下，从想尽办法控制注入到不做控制，一股脑全部注入进去，然后按规则过滤。有时候，其实遇到一条思路走不通的时候，可以反过来想想，也许就会走通。
以上所述就是小编给大家介绍的《spring实现根据controller中接收请求参数不同走不同service》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
The Art of Computer Programming, Volume 4, Fascicle 3
Donald E. Knuth / Addison-Wesley Professional / 2005-08-05 / USD 19.99
Finally, after a wait of more than thirty-five years, the first part of Volume 4 is at last ready for publication. Check out the boxed set that brings together Volumes 1 - 4A in one elegant case, and ......一起来看看 《The Art of Computer Programming, Volume 4, Fascicle 3》 这本书的介绍吧!
