Spring中的配置怎么保證可擴展性

本篇內容介紹了“Spring中的配置怎么保證可擴展性”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

公司項目引用了一個依賴jar，配置封裝太封閉了，不能擴展。業務變動一次那個jar就要跟著升級一次，而且不同的項目還引用了這個jar的不同版本。領導問我能不能給它搞成可擴展的，研究了一下，實現了可擴展定制化。

原本的配置類似是這樣的：

@Configuration(proxyBeanMethods = false) public class MyConfiguration {      /**      * bean      */     @Bean     ConfigBean configBean(Config config)  {         //todo 邏輯      return new ConfigBean(config)     }      }

如果想根據項目的不同定制不同的ConfigBean就不太好弄了。如果能在Config對象傳入ConfigBean構造之前放一個修改Config的口子就好了。這樣ConfigBean的初始化生命周期也變成了

發現Config對象-> 修改Config對象-> 初始化ConfigBean

于是我定義了一個可以修改Config對象的接口：

@FunctionalInterface public interface ConfigCustomizer {      /**      * Customize.      *      * @param config the config      */     void customize(Config config); }

上面整個配置就變成這樣的了：

@Configuration(proxyBeanMethods = false) public class MyConfiguration {     private List<ConfigCustomizer> configCustomizers = Collections.emptyList();     /**      * bean      */     @Bean     ConfigBean configBean(Config config)  {                  // 其它公共邏輯省略                  // 最后定制邏輯注入         configCustomizers                 .forEach(configCustomizer -> configCustomizer.customize(config));      return new ConfigBean(config)     }          @Autowired(required = false)     void setConfigCustomizers(List<ConfigCustomizer> configCustomizers) {         this.configCustomizers = configCustomizers;     } }

這樣我們需要改動配置時只需要聲明一個ConfigCustomizerBean即可，它會被setConfigCustomizers自動發現并執行自定義的方法。

這里會有朋友說@ConditionalOnMissingBean系列注解也能干這個事啊，沒錯!這樣我們完全可以聲明一個新的ConfigBean取而代之。但是這是兩種策略：一種是修修補補就能用;一種是推到重來。我們在封裝組件的時候要合理利用這些策略，該開口子的要開口子，不該開放的保持封閉，另外保證組件的擴展性也是很重要的。

“Spring中的配置怎么保證可擴展性”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！