我们知道，在项目中，很多时候需要用到一些配置的信息，这些信息可能在测试环境和生产环境下会有不同的配置，后面根据实际业务情况有可能还会做修改，针对这种情况，我们不能将这些配置在代码中写死，最好就是写到配置文件中。比如可以把这些信息写到 application.yml 文件中。
- 少量配置信息的情形
举个例子，在微服务架构中，最常见的就是某个服务需要调用其他服务来获取其提供的相关信息，那么在该服务的配置文件中需要配置被调用的服务地址，比如在当前服务里，我们需要调用订单微服务获取订单相关的信息，假设 订单服务的端口号是 8002，那我们可以做如下配置：
server:
port: 8001
配置微服务的地址
url:
订单微服务的地址
orderUrl: http://localhost:8002
然后在业务代码中如何获取到这个配置的订单服务地址呢？我们可以使用 @Value 注解来解决。在对应的类中加上一个属性，在属性上使用 @Value 注解即可获取到配置文件中的配置信息，如下：
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/test")
public class ConfigController {
private static final Logger LOGGER = LoggerFactory.getLogger(ConfigController.class);
@Value("${url.orderUrl}")
private String orderUrl;
@RequestMapping("/config")
public String testConfig() {
LOGGER.info("=====获取的订单服务地址为：{}", orderUrl);
return "success";
}
}
@Value 注解上通过 ${key} 即可获取配置文件中和 key 对应的 value 值。我们启动一下项目，在浏览器中输入 localhost:8080/test/config 请求服务后，可以看到控制台会打印出订单服务的地址：
=====获取的订单服务地址为：http://localhost:8002
说明我们成功获取到了配置文件中的订单微服务地址，在实际项目中也是这么用的，后面如果因为服务器部署的原因，需要修改某个服务的地址，那么只要在配置文件中修改即可。
多个配置信息的情形
这里再引申一个问题，随着业务复杂度的增加，一个项目中可能会有越来越多的微服务，某个模块可能需要调用多个微服务获取不同的信息，那么就需要在配置文件中配置多个微服务的地址。可是，在需要调用这些微服务的代码中，如果这样一个个去使用 @Value 注解引入相应的微服务地址的话，太过于繁琐，也不科学。
所以，在实际项目中，业务繁琐，逻辑复杂的情况下，需要考虑封装一个或多个配置类。举个例子：假如在当前服务中，某个业务需要同时调用订单微服务、用户微服务和购物车微服务，分别获取订单、用户和购物车相关信息，然后对这些信息做一定的逻辑处理。那么在配置文件中，我们需要将这些微服务的地址都配置好：配置多个微服务的地址
url:
订单微服务的地址
orderUrl: http://localhost:8002
用户微服务的地址
userUrl: http://localhost:8003
购物车微服务的地址
shoppingUrl: http://localhost:8004
也许实际业务中，远远不止这三个微服务，甚至十几个都有可能。对于这种情况，我们可以先定义一个 MicroServiceUrl 类来专门保存微服务的 url，如下：
@Component
@ConfigurationProperties(prefix = "url")
public class MicroServiceUrl {private String orderUrl;
private String userUrl;
private String shoppingUrl;
// 省去get和set方法
}
细心的朋友应该可以看到，使用 @ConfigurationProperties 注解并且使用 prefix 来指定一个前缀，然后该类中的属性名就是配置中去掉前缀后的名字，一一对应即可。即：前缀名 + 属性名就是配置文件中定义的 key。同时，该类上面需要加上 @Component 注解，把该类作为组件放到Spring容器中，让 Spring 去管理，我们使用的时候直接注入即可。
需要注意的是，使用 @ConfigurationProperties 注解需要导入它的依赖：
org.springframework.boot
spring-boot-configuration-processor
true
OK，到此为止，我们将配置写好了，接下来写个 Controller 来测试一下。此时，不需要在代码中一个个引入这些微服务的 url 了，直接通过 @Resource 注解将刚刚写好配置类注入进来即可使用了，非常方便。如下：
@RestController
@RequestMapping("/test")
public class TestController {private static final Logger LOGGER = LoggerFactory.getLogger(TestController.class);
@Resource
private MicroServiceUrl microServiceUrl;@RequestMapping("/config")
public String testConfig() {LOGGER.info("=====获取的订单服务地址为：{}", microServiceUrl.getOrderUrl()); LOGGER.info("=====获取的用户服务地址为：{}", microServiceUrl.getUserUrl()); LOGGER.info("=====获取的购物车服务地址为：{}", microServiceUrl.getShoppingUrl()); return "success";}
}
再次启动项目，请求一下可以看到，控制台打印出如下信息，说明配置文件生效，同时正确获取配置文件内容：
=====获取的订单服务地址为：http://localhost:8002
=====获取的订单服务地址为：http://localhost:8002
=====获取的用户服务地址为：http://localhost:8003
=====获取的购物车服务地址为：http://localhost:8004- 指定项目配置文件
我们知道，在实际项目中，一般有两个环境：开发环境和生产环境。开发环境中的配置和生产环境中的配置往往不同，比如：环境、端口、数据库、相关地址等等。我们不可能在开发环境调试好之后，部署到生产环境后，又要将配置信息全部修改成生产环境上的配置，这样太麻烦，也不科学。
最好的解决方法就是开发环境和生产环境都有一套对用的配置信息，然后当我们在开发时，指定读取开发环境的配置，当我们将项目部署到服务器上之后，再指定去读取生产环境的配置。
我们新建两个配置文件： application-dev.yml 和 application-pro.yml，分别用来对开发环境和生产环境进行相关配置。这里为了方便，我们分别设置两个访问端口号，开发环境用 8001，生产环境用 8002.开发环境配置文件
server:
port: 8001开发环境配置文件
server:
port: 8002
然后在 application.yml 文件中指定读取哪个配置文件即可。比如我们在开发环境下，指定读取 applicationn-dev.yml 文件，如下：
spring:
profiles:
active:- dev
这样就可以在开发的时候，指定读取 application-dev.yml 文件，访问的时候使用 8001 端口，部署到服务器后，只需要将 application.yml 中指定的文件改成 application-pro.yml 即可，然后使用 8002 端口访问，非常方便。
- dev
- 总结
本节课主要讲解了 Spring Boot 中如何在业务代码中读取相关配置，包括单一配置和多个配置项，在微服务中，这种情况非常常见，往往会有很多其他微服务需要调用，所以封装一个配置类来接收这些配置是个很好的处理方式。除此之外，例如数据库相关的连接参数等等，也可以放到一个配置类中，其他遇到类似的场景，都可以这么处理。最后介绍了开发环境和生产环境配置的快速切换方式，省去了项目部署时，诸多配置信息的修改。课程源代码下载地址：戳我下载
第05课：Spring Boot中的MVC支持
Spring Boot 的 MVC 支持主要来介绍实际项目中最常用的几个注解，包括 @RestController、 @RequestMapping、@PathVariable、@RequestParam 以及 @RequestBody。主要介绍这几个注解常用的使用方式和特点。 - @RestController
@RestController 是 Spring Boot 新增的一个注解，我们看一下该注解都包含了哪些东西。
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
public @interface RestController {
String value() default "";
}
可以看出， @RestController 注解包含了原来的 @Controller 和 @ResponseBody 注解，使用过 Spring 的朋友对 @Controller 注解已经非常了解了，这里不再赘述， @ResponseBody 注解是将返回的数据结构转换为 Json 格式。所以 @RestController 可以看作是 @Controller 和 @ResponseBody 的结合体，相当于偷个懒，我们使用 @RestController 之后就不用再使用 @Controller 了。但是需要注意一个问题：如果是前后端分离，不用模板渲染的话，比如 Thymeleaf，这种情况下是可以直接使用@RestController 将数据以 json 格式传给前端，前端拿到之后解析；但如果不是前后端分离，需要使用模板来渲染的话，一般 Controller 中都会返回到具体的页面，那么此时就不能使用@RestController了，比如：
public String getUser() {
return "user";
}
其实是需要返回到 user.html 页面的，如果使用 @RestController 的话，会将 user 作为字符串返回的，所以这时候我们需要使用 @Controller 注解。这在下一节 Spring Boot 集成 Thymeleaf 模板引擎中会再说明。 @RequestMapping
@RequestMapping 是一个用来处理请求地址映射的注解，它可以用于类上，也可以用于方法上。在类的级别上的注解会将一个特定请求或者请求模式映射到一个控制器之上，表示类中的所有响应请求的方法都是以该地址作为父路径；在方法的级别表示进一步指定到处理方法的映射关系。
该注解有6个属性，一般在项目中比较常用的有三个属性：value、method 和 produces。
● value 属性：指定请求的实际地址，value 可以省略不写
● method 属性：指定请求的类型，主要有 GET、PUT、POST、DELETE，默认为 GET
● produces属性：指定返回内容类型，如 produces = "application/json; charset=UTF-8"
@RequestMapping 注解比较简单，举个例子：
@RestController
@RequestMapping(value = "/test", produces = "application/json; charset=UTF-8")
public class TestController {@RequestMapping(value = "/get", method = RequestMethod.GET)
public String testGet() {return "success";}
}
这个很简单，启动项目在浏览器中输入 localhost:8080/test/get 测试一下即可。
针对四种不同的请求方式，是有相应注解的，不用每次在 @RequestMapping 注解中加 method 属性来指定，上面的 GET 方式请求可以直接使用 @GetMapping("/get") 注解，效果一样。相应地，PUT 方式、POST 方式和 DELETE 方式对应的注解分别为 @PutMapping、@PostMapping 和 DeleteMapping。- @PathVariable
@PathVariable 注解主要是用来获取 url 参数，Spring Boot 支持 restfull 风格的 url，比如一个 GET 请求携带一个参数 id 过来，我们将 id 作为参数接收，可以使用 @PathVariable 注解。如下：
@GetMapping("/user/{id}")
public String testPathVariable(@PathVariable Integer id) {
System.out.println("获取到的id为：" + id);
return "success";
}
这里需要注意一个问题，如果想要 url 中占位符中的 id 值直接赋值到参数 id 中，需要保证 url 中的参数和方法接收参数一致，否则就无法接收。如果不一致的话，其实也可以解决，需要用 @PathVariable 中的 value 属性来指定对应关系。如下：
@RequestMapping("/user/{idd}")
public String testPathVariable(@PathVariable(value = "idd") Integer id) {
System.out.println("获取到的id为：" + id);
return "success";
}
对于访问的 url，占位符的位置可以在任何位置，不一定非要在最后，比如这样也行：/xxx/{id}/user。另外，url 也支持多个占位符，方法参数使用同样数量的参数来接收，原理和一个参数是一样的，例如：
@GetMapping("/user/{idd}/{name}")
public String testPathVariable(@PathVariable(value = "idd") Integer id, @PathVariable String name) {
}System.out.println("获取到的id为：" + id); System.out.println("获取到的name为：" + name); return "success";
运行项目，在浏览器中请求 localhost:8080/test/user/2/zhangsan 可以看到控制台输出如下信息：
获取到的id为：2
获取到的name为：zhangsan
所以支持多个参数的接收。同样地，如果 url 中的参数和方法中的参数名称不同的话，也需要使用 value 属性来绑定两个参数。 - @RequestParam
@RequestParam 注解顾名思义，也是获取请求参数的，上面我们介绍了 @PathValiable 注解也是获取请求参数的，那么 @RequestParam 和 @PathVariable 有什么不同呢？主要区别在于： @PathValiable 是从 url 模板中获取参数值， 即这种风格的 url：http://localhost:8080/user/{id} ；而 @RequestParam 是从 request 里面获取参数值，即这种风格的 url：http://localhost:8080/user?id=1 。我们使用该 url 带上参数 id 来测试一下如下代码：
@GetMapping("/user")
public String testRequestParam(@RequestParam Integer id) {
System.out.println("获取到的id为：" + id);
return "success";
}
可以正常从控制台打印出 id 信息。同样地，url 上面的参数和方法的参数需要一致，如果不一致，也需要使用 value 属性来说明，比如 url 为：http://localhost:8080/user?idd=1
@RequestMapping("/user")
public String testRequestParam(@RequestParam(value = "idd", required = false) Integer id) {
System.out.println("获取到的id为：" + id);
return "success";
}
除了 value 属性外，还有个两个属性比较常用：
● required 属性：true 表示该参数必须要传，否则就会报 404 错误，false 表示可有可无。
● defaultValue 属性：默认值，表示如果请求中没有同名参数时的默认值。
从 url 中可以看出，@RequestParam 注解用于 GET 请求上时，接收拼接在 url 中的参数。除此之外，该注解还可以用于 POST 请求，接收前端表单提交的参数，假如前端通过表单提交 username 和 password 两个参数，那我们可以使用 @RequestParam 来接收，用法和上面一样。
@PostMapping("/form1")
public String testForm(@RequestParam String username, @RequestParam String password) {
}System.out.println("获取到的username为：" + username); System.out.println("获取到的password为：" + password); return "success";
我们使用 postman 来模拟一下表单提交，测试一下接口：
那么问题来了，如果表单数据很多，我们不可能在后台方法中写上很多参数，每个参数还要 @RequestParam 注解。针对这种情况，我们需要封装一个实体类来接收这些参数，实体中的属性名和表单中的参数名一致即可。
public class User {
private String username;
private String password;
// set get
}
使用实体接收的话，我们不能在前面加 @RequestParam 注解了，直接使用即可。
@PostMapping("/form2")
public String testForm(User user) {
System.out.println("获取到的username为：" + user.getUsername());
System.out.println("获取到的password为：" + user.getPassword());
return "success";
}
使用 postman 再次测试一下表单提交，观察一下返回值和控制台打印出的日志即可。在实际项目中，一般都是封装一个实体类来接收表单数据，因为实际项目中表单数据一般都很多。
- @RequestBody
@RequestBody 注解用于接收前端传来的实体，接收参数也是对应的实体，比如前端通过 json 提交传来两个参数 username 和 password，此时我们需要在后端封装一个实体来接收。在传递的参数比较多的情况下，使用 @RequestBody 接收会非常方便。例如：
public class User {
private String username;
private String password;
// set get
}
@PostMapping("/user")
public String testRequestBody(@RequestBody User user) {
System.out.println("获取到的username为：" + user.getUsername());
System.out.println("获取到的password为：" + user.getPassword());
return "success";
}
我们使用 postman 工具来测试一下效果，打开 postman，然后输入请求地址和参数，参数我们用 json 来模拟，如下图所有，调用之后返回 success。
同时看一下后台控制台输出的日志：
获取到的username为：倪升武
获取到的password为：123456
可以看出，@RequestBody 注解用于 POST 请求上，接收 json 实体参数。它和上面我们介绍的表单提交有点类似，只不过参数的格式不同，一个是 json 实体，一个是表单提交。在实际项目中根据具体场景和需要使用对应的注解即可。
- 总结
本节课主要讲解了 Spring Boot 中对 MVC 的支持，分析了 @RestController、 @RequestMapping、@PathVariable、 @RequestParam 和 @RequestBody 四个注解的使用方式，由于 @RestController 中集成了 @ResponseBody 所以对返回 json 的注解不再赘述。以上四个注解是使用频率很高的注解，在所有的实际项目中基本都会遇到，要熟练掌握。
