spring实现根据controller中接收请求参数不同走不同service

栏目: Java · 发布时间: 5年前

内容简介:前几天一个工程中,需要实现这样一个场景:根据前端发送过来的请求参数的不同,走不同的 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 机制实现的,可以简单的这样理解 FactoryBeanFactoryBean 是生成普通 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》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

数据挖掘技术

数据挖掘技术

[美]MichaelJ.A.B / 别荣芳、尹静、邓六爱 / 机械工业 / 2006-7 / 49.00元

本书是数据挖掘领域的经典著作,数年来畅销不衰。全书从技术和应用两个方面,全面、系统地介绍了数据挖掘的商业环境、数据挖掘技术及其在商业环境中的应用。自从1997年本书第1版出版以来,数据挖掘界发生了巨大的变化,其中的大部分核心算法仍然保持不变,但是算法嵌入的软件、应用算法的数据库以及用于解决的商业问题都有所演进。第2版展示如何利用基本的数据挖掘方法和技术,解决常见的商业问题。 本书涵盖核心的数......一起来看看 《数据挖掘技术》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具