快捷導(dǎo)航

spring根據(jù)controller中接收請求參數(shù)不同走不同service的實現(xiàn)方法

更新時間：2018年11月13日 10:21:44 作者：Since1986

這篇文章主要給大家介紹了關(guān)于spring實現(xiàn)根據(jù)controller中接收請求參數(shù)不同走不同service的相關(guān)資料，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友可以參考下

前言

前幾天一個工程中，需要實現(xiàn)這樣一個場景：根據(jù)前端發(fā)送過來的請求參數(shù)的不同，走不同的 service（可同事走多個），最初我的思路是嘗試實現(xiàn)在 spring 中實現(xiàn)動態(tài)的依賴注入，也就是根據(jù)請求參數(shù)，動態(tài)的在 controller 中注入某個 service 接口的特定實現(xiàn)（接口有多個實現(xiàn)），但是發(fā)現(xiàn)這個實現(xiàn)不了，然后想了想，換了個思路，重新設(shè)計了一下，實現(xiàn)了需求中的場景。

附controller的分類：

正文

我的解決辦法是，使用“生產(chǎn)線工人工作能力自己掂量機制”來解決，這名字我自己起的，實際上就是想要實現(xiàn)按參數(shù)選擇走哪個 service 實現(xiàn)，可以一次性把所有 service 實現(xiàn)全都注入進來，然后依次請求，同時在每個 service 實現(xiàn)中寫一套規(guī)則判別方法，判斷當前請求自己是不是能夠處理，如果能夠處理，則進入處理方法，若自己沒有處理能力，則退出，讓請求走到其他 service 做同樣的判斷。形象點，可以想象一下，在一條生產(chǎn)線的傳送帶上傳送著不同品類的待加工的元部件，有若干工人排列在傳送帶旁邊，每個工人只會加工某一種元件，那么，當傳送帶上的元件傳送到自己面前時，需要判斷一下，自己有沒有處理這個元件的能力（掂量一下自己的能力），若有，取過來處理，若沒有，放過去讓別人走流程。

理解了其中邏輯，我們就來看代碼吧（片段）：

public interface ServiceProvider {

 // 掂量一下自己有沒有能力加工當前的元件（也就是Request），能就返回 true 不能返回 false
 boolean support(Request request);

 // 具體加工元件的邏輯
 Response execute(Request request);
}

@Service
public class ServiceImpl implements Service {

 // 注入一系列 service 數(shù)量不定 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 // 循環(huán)每個 service TODO 現(xiàn)在時間復(fù)雜度為 O(n) 可以嘗試優(yōu)化為 O(logn)
   .stream()
   .filter(serviceProvider -> serviceProvider.support(request)) // 按加工能力過濾
   .map(serviceProvider -> serviceProvider.execute(request)) // 執(zhí)行 service 得 execute 方法
   .collect(Collectors.toList());
 }
}

這里有一點需要解釋一下，在上面第二段代碼中，有這么一段：

@Resource(name = "serviceProviders")
private List<ServiceProvider> serviceProviders;

這里是使用 spring 中的 FactoryBean 機制實現(xiàn)的，可以簡單的這樣理解 FactoryBean ：FactoryBean 是生成普通 Bean 的 Bean，當注入 FactoryBean 時，默認注入的是其生產(chǎn)出來的所有普通 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;
 }
}

通過這樣的設(shè)計，就完成了我們的需求，實際上我們等于把思路反轉(zhuǎn)了一下，從想盡辦法控制注入到不做控制，一股腦全部注入進去，然后按規(guī)則過濾。有時候，其實遇到一條思路走不通的時候，可以反過來想想，也許就會走通。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

您可能感興趣的文章: