因为spring里面有很多配置其实一旦配置完成就不会去改变了,而且也没必要改变,例如大多数bean的依赖关系。把这些不会改变的配置都放在xml里面是没有意义的,只是会让配置越来越大,spring 3.x的时候就被诟病配置太多,已经变成了基于配置编程了,本末倒置了,所以把这些近乎静态的配置放在代码里面其实更好。 XML更方便修改,而且无需编译即可生效,所以把那些需要根据环境,业务改变的配置放在XML里面更好。 Spring Boot吸收了Rails的配置基于约定的方式,使得配置减少了很多,不过如果不熟悉它的底层是怎么配置的话,可能会遇到很多问题。
配置写在代码里面更加直观,简单(有的配置 spring boot 自己已经做了),使用链式编程。。。
使用 maven 依赖更加清爽。
但是我觉得坑比较多
因为spring里面有很多配置其实一旦配置完成就不会去改变了,而且也没必要改变,例如大多数bean的依赖关系。把这些不会改变的配置都放在xml里面是没有意义的,只是会让配置越来越大,spring 3.x的时候就被诟病配置太多,已经变成了基于配置编程了,本末倒置了,所以把这些近乎静态的配置放在代码里面其实更好。
XML更方便修改,而且无需编译即可生效,所以把那些需要根据环境,业务改变的配置放在XML里面更好。
Spring Boot吸收了Rails的配置基于约定的方式,使得配置减少了很多,不过如果不熟悉它的底层是怎么配置的话,可能会遇到很多问题。
这个我也觉得有点无语。
一定要解释的话,Spring时代前的Java配置是命令式的(一路写下来,依赖执行顺序),改成了XML声明式,到了Spring Boot时代,又实现了声明式的Java配置(分散在多个被注解的方法中,不依赖执行顺序)。
另外很多配置可以用application.properties覆盖,早该这样嘛!