好得很程序员自学网

<tfoot draggable='sEl'></tfoot>

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

前言

前几天一个工程中,需要实现这样一个场景:根据前端发送过来的请求参数的不同,走不同的 service(可同事走多个),最初我的思路是尝试实现在 spring 中实现动态的依赖注入,也就是根据请求参数,动态的在 controller 中注入某个 service 接口的特定实现(接口有多个实现),但是发现这个实现不了,然后想了想,换了个思路,重新设计了一下,实现了需求中的场景。

附controller的分类:

  

正文

我的解决办法是,使用[生产线工人工作能力自己掂量机制]来解决,这名字我自己起的,实际上就是想要实现按参数选择走哪个 service 实现,可以一次性把所有 service 实现全都注入进来,然后依次请求,同时在每个 service 实现中写一套规则判别方法,判断当前请求自己是不是能够处理,如果能够处理,则进入处理方法,若自己没有处理能力,则退出,让请求走到其他 service 做同样的判断。形象点,可以想象一下,在一条生产线的传送带上传送着不同品类的待加工的元部件,有若干工人排列在传送带旁边,每个工人只会加工某一种元件,那么,当传送带上的元件传送到自己面前时,需要判断一下,自己有没有处理这个元件的能力(掂量一下自己的能力),若有,取过来处理,若没有,放过去让别人走流程。

理解了其中逻辑,我们就来看代码吧(片段):

?

1

2

3

4

5

6

7

8

public interface serviceprovider {

 

  // 掂量一下自己有没有能力加工当前的元件(也就是request),能就返回 true 不能返回 false

  boolean support(request request);

 

  // 具体加工元件的逻辑

  response execute(request request);

}

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

@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());

  }

}

这里有一点需要解释一下,在上面第二段代码中,有这么一段:

?

1

2

@resource (name = "serviceproviders" )

private list<serviceprovider> serviceproviders;

这里是使用 spring 中的 factorybean 机制实现的,可以简单的这样理解 factorybean :factorybean 是生成普通 bean 的 bean,当注入 factorybean 时,默认注入的是其生产出来的所有普通 bean,而不是它自己。

在上边代码中,注入的名为 serviceproviders 的这个 bean,实际上是这样定义出来的:

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

@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;

  }

}

通过这样的设计,就完成了我们的需求,实际上我们等于把思路反转了一下,从想尽办法控制注入到不做控制,一股脑全部注入进去,然后按规则过滤。有时候,其实遇到一条思路走不通的时候,可以反过来想想,也许就会走通。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对的支持。

原文链接:https://since1986.github.io/blog/a9b7a8df.html

查看更多关于spring根据controller中接收请求参数不同走不同service的实现方法的详细内容...

  阅读:45次