本篇内容介绍了“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 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 configcustomizers) { this.configcustomizers = configcustomizers; } }
这样我们需要改动配置时只需要声明一个configcustomizerbean即可，它会被setconfigcustomizers自动发现并执行自定义的方法。
这里会有朋友说@conditionalonmissingbean系列注解也能干这个事啊，没错!这样我们完全可以声明一个新的configbean取而代之。但是这是两种策略：一种是修修补补就能用;一种是推到重来。我们在封装组件的时候要合理利用这些策略，该开口子的要开口子，不该开放的保持封闭，另外保证组件的扩展性也是很重要的。
“spring中的配置怎么保证可扩展性”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注本站网站，小编将为大家输出更多高质量的实用文章！
