为什么boot更快捷
更多的人选择Spring-Boot进行开发，其中有两个原因
-
Spring-Cloud,Spring-Data等组件丰富且全套 -
Spring-Boot携带适配很多框架，且能够快速搭建环境，抽出更多时间针对业务逻辑开展工作
之所以使用人员那么多，大多基于第二种原因
不过随着发展，第一种因素吸引了更多的技术人员
但是，不可避免的反面声音：Spring-Boot不过是一个大杂烩。
对流行的框架进行适配，搭建很快速，但是没有新东西。
是这样么？
的确，
Spring-Boot的确适配了太多的流行框架，让人忽略了它自身的东西。我觉得，
Spring-Boot最重要的技术，就是适配，基于适配，才完美衔接了前后的发展潮流。至于因为
适配其他框架，只不过是一个附加的功用，但是也体现了Spring-Boot的成功。
为什么能够轻松适配呢，贯穿始终的，就是自动配置，手写一个starter感受一下。
starter
1. 基本结构
- 目录结构
- starter
一个空工程，只是做了一个关系整合，除
maven导入和其他配置，没有其他代码。
autoConfig
就是它了，核心就是一个自动配置类，然后被
starter引入。从而完成了各种
适配
- 代码结构
三个关键要素
service：就是服务啦，自定义的，或者就是其他框架properties:配置类，@ConfigurationProperties这个现在又大用autoConfig：主要的就是这东西，逻辑就是这组装的
2. 配置
- 依赖
其他什么
spring-boot-starter-test，plugin不需要的都去掉吧，反正这不是一个启动项目。
- 初始化
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.godme.spring.boot.autoconfig.config.MyAutoConfig
resources/META-INF/spring.factories下面，没忘吧
具体代码
service
public class MyService {
public void setProp(MyProperties prop) {
this.prop = prop;
}
private MyProperties prop;
public String getInfo(){
return prop.toString();
}
}
反正其他不管，基础服务内部是一定要有配置的。
如果没有，也不是不可以，了解流程以后随便玩
properties
@ConfigurationProperties(prefix = "godme.prop")
public class MyProperties {
private String name;
private String male;
private int age;
}
@ConfigurationProperties主体就是这个了，关键要指定
AutoConfig
@Configuration
@ConditionalOnWebApplication
@EnableConfigurationProperties(MyProperties.class)
public class MyAutoConfig {
@Autowired
MyProperties prop;
@Bean
public MyService myService(){
MyService service = new MyService();
service.setProp(prop);
return service;
}
}
@Configuration：这个可少不得，说实话，所谓自动配置，就是早自动注入需要对象
@ConditionalOnWebApplication：一堆条件注解，控制生效时间
@EnableConfigurationProperties:指定配置类MyProperties.class里面就是
@Autowired配置，然后注入服务并添加到容器这就是为什么好多东西不用经过配置就能够直接引用的关键
没有配置有默认，新配置就替换，都是
条件注解，可以多了解一些@ConditionalOn*
pom
<dependency>
<groupId>com.godme</groupId>
<artifactId>godme-spring-boot-starter-autoconfig</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
测试一下
pom
<dependency>
<groupId>com.godme</groupId>
<artifactId>godme-spring-boot-starer</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
controller
@RestController
public class MyController {
@Autowired
MyService myService;
@RequestMapping("/service")
public String service(){
return myService.getInfo();
}
}
properties
godme.prop.name=godme
godme.prop.male=male
godme.prop.age=99
结果
MyProperties{name='godme', male='male', age=99}
本质分析
所谓服务
不论是框架还是后续的组件,只要需要调用，需要配置，都可以进行管理.
好比日志替换包，我们也可以把服务进行包装，然后方便注入我们的配置。
所谓配置
就是抽取服务的配置，然后通过@ConfigurationProperties进行绑定，从而达到在配置文件application.yml或application.properties中配置映射到内存的方法。
所谓自动
@Autowired自动引入了配置，EnableConfigurationProperties使能，实例化service并添加到容器.
service中的流程通过properties进行控制。
当然啦，没有服务的话，我们只注入properteis也可以，反正也能用得上。
甚至可能是自动配置注入properties，我们通过properties来管理正在编写的service。
先有
service，然后注入properties，实例化注入properties之后的service,这就是适配.单独的
properties，就是自动注入配置文件。开发过程中也可以先指定规范
properties，然后再进行service的实现，也都是可以的。
逻辑简单，关键在于@ConditionalOn*的生效场景的编写，熟悉更多的@ConditionalOn*，就能够玩转一切。
所谓starter
- 虚名
starter都是空包，关键在于autoConfig的整合
- 流程
condition->properties->autoConfig->service->context满足场景，就自动注入了需要的对象。
不是
适配，而是满足条件就配置。不是没做，而是全部都完成了。
- 使用
最大的优点，就是自动模块化实现插入。
正如前面我们所说的流程注入，当我们都需要进行监控时，编写一个基本的
starter。每次引入注容器以后自动生效，在关键步骤触发，
复用率简直爆炸。而且够方便，够快捷，简直不要太懒了
- 归纳
- starter
编写的步骤不繁琐，主要在于@ConditionalOn*的场景触发。
- 可能
适配
已有入服务基础上进行
配置,适配各种框架规范
单独注入
properteis,控制开发流程，规范开发结构流程
starter中自动注入原装流程，Spring-Boot自动调用，导入即自动生效服务
如
mybatis,全实现，供调用
- 实质
Spring-Boot提供的是一套的从配置文件properteis到影响service的配置方案。不离开
注入这一思想，深化了配置这一概念。通过
properties就能够为代码中注入可调用的实例,不论是配置或是服务。简单的配置就能够操控代码的行为，暴露了一个十分强大的接口。
在编写代码过程中，不用再手动的读取配置，也让
个人配置高大上起来，也更规范.
IOC常用，但思维总局限于边边角角，现在更加深刻了一点。我们不仅能够
注入对象，还能注入服务，注入模块能够
@ConditionalOn*考虑场景的生效。能够导入后直接调用
service.当插入
Spring-Boot自身的流程操作，还能自动管理,自动监控.对于已经实现的
starter，直接引入不仅模块导入，而是能够直接运用。
Spring-Boot不是没做啥，而是做了很多.
不仅提供了新的自动配置,还已经实现了如此之多的自动配置.
一个自动配置,不仅完美的适配了众多框架，更是让全部的框架,成为了它的插件.