共计 3234 个字符，预计需要花费 9 分钟才能阅读完成。
在大型软件系统设计时，业务个别会绝对简单，如果所有业务实现的代码都纠缠在一起，会呈现逻辑不清晰、可读性差，保护艰难，改变一处就牵一发而动全身等问题。生存和理论我的项目中对相似问题的解决方案往往“分而治之”的思维，以升高业务的复杂度，进步其可维护性。这就用到了分层架构设计，MVC 设计思维诞生。
MVC:
1. 分层设计思维
2. 一种套路或设计模式
3.model view controller 的缩写
3.1 model(业务逻辑对象)
3.2 view(显示逻辑对象)
3.3 controller(管制逻辑对象)
Spring 中 Web 模块基于 MVC 设计思维做了落地的实现，其外围组件有:
1.DipatcherServlet(sprign mvc 外围控制器)
2.RequestMapping(封装的申请映射 ->url 到具体的 handler 及办法之间的映射)
3.Handler(申请处理器 -> 负责解决 Controller 获取申请 -> 能够将其了解为 model)
4.ModelAndView(封装业务数据和视图信息的对象; 一个 handler 办法就算没有 Model，底层也会将 view 存储到 ModelAndView 中)
5.ViewResolver(负责视图模板解析的对象 ->View)
url 申请的繁难处理过程:
1. 基于域名获取 ip 地址 (127.0.0.1)
2. 基于 ip 找到网络中的计算机(ip 地址是网络中计算机的惟一标识)
3. 基于端口找到 tomcat 服务(port 是计算机中利用的惟一标识)
4.tomcat 服务会基于 thread 并借助 io 读取网络 http 协定中申请数据
5.tomcat 外部会创立申请(request) 和响应 (response) 对象，用于封装申请和响应信息
6.tomcat 会调用 Filter 对象对 request 数据进行过滤
7.Filter 对 request 过滤当前，会将申请交给 DispatcherServlet 进行解决
8.DispatcherServlet 读取申请中的 url，并基于 url 从 requestMapping 中找到对应的 handler 以及办法
9.DispatcherServlet 基于反射技术调用 handler 办法
10.DispatcherServlet 会将 handler 办法返回的 view 等信息进行封装，而后交给视图解析器(ViewResolver) 进行解析
11. 视图解析器会为 view 增加前缀(templates) 和后缀 (.html)，并将 model 中数据填充到 view 中
12.DispatcherServlet 将视图解析器(ViewResolver) 解析的后果封装到 respones 对象并将其响应到客户端
static 目录剖析
1. 能够存储内容:html,css,image
2. 能够通过浏览器间接拜访, 但不能被 spring 中视图解析器进行解析
3.SpringBoot 底层默认指定 static 目录, 在拜访时不须要在 url 门路中加上 static 目录
templates 目录剖析
1. 不能被网页之间拜访, 必须通过 handler 办法
2.html 放在此目录，能够赋予 html 更多的性能(例如 EL 表达式,if 分支语句,for 循环语句)
3. 雷同 url，此目录的优先级更高
4. 存储 html 模板文件
SpringBoot 工程中的 static 和 templates 目录中的 html，默认对其内容批改后, 不重启服务，只刷新网页是看不到批改的内容的。如果想批改后不必重启服务就能看到内容须要做如下操作:
1. 批改 idea 默认配置，容许主动编译，如图所示:
2. 如果是 templates 目录下的还须要在 SpringBoot 工程的配置文件中配置:
响应数据的解决
响应的数据有静态数据 -html/css/js/images, 动态数据 - 业务数据。这些数据个别封装到 ModelAndView 中, 通过 model 封装业务数据，通过 view 封装 html 页面。
Model
存储了 View 中须要出现的数据的对象，model 底层是 Map
thymeleaf
是一个以 html 为模板的模板引擎，此引擎为 htmk 元素增加额定属性并进行解析，而后对其进行赋能。SpringBoot 工程中对 thymeleaf 做了默认的反对与配置。SpringBoot 工程中 thymeleaf 默认的前后缀别离是:
1. 前缀 spring.thymeleaf.prefix=classpath:/templates/
2. 后缀 spring.thymeleaf.suffix=.html
响应的业务数据转换为 Json 格局字符串写到客户端
Json 是一种反对跨端需要的轻量级数据格式 (例如{“key”:Value1;”Key2″:”Value2″});
转换为 Json 格局是为了跨端, 为了解析更不便;
SpringBoot 工程默认应用的是 jackson 这一组 api 将响应的业务数据转换为 Json 格局的，这组依赖是在增加了 Spring Web 依赖之后主动引入的。
这个 Json 格局的字符串会写到 http 协定的响应体中，而后响应到客户端
若业务数据是 pojo 对象, 那么在转换为 Json 格局的时候会默认调用 pojo 对象的 get 办法，会应用 get 办法名中 get 单词前面的名字作为 key(首字母小写)，get 办法的返回值作为 value，拼接 json 格局字符串，如果 pojo 对象中没有提供 get 办法，就会报异样。办法要用 @ResponseBody 形容。
若业务数据是 map 时，那么在转换为 Json 格局的时候也是用了 jackson 这组 api，objectMapper.writeValueAsString(map); 转换为字符串。办法要用 @ResponseBody 形容。
申请参数的解决
传统的 java web 利用, 在 servlet 中获取申请数据, 咱们是用 HttpServletRequest 对象获取申请中的 utl, 参数等相干信息(request.getParameter(“…”)), 当咱们获取到这些参数后或者还要进行参数的解析和转换等操作。申请参数的获取, 解析, 封装这样的过程, 在咱们的程序中可能会重复呈现。
在 SpringBoot 工程中 Web 申请参数的解决:
1. 在管制逻辑办法参数中基于间接量 (String,8 种封装类,Date) 接管申请数据
1.1 间接量的形式办法的参数的变量必须和 url 申请的参数名统一
1.2 如果办法要接管日期格局对象能够通过 @DateTimeFormat 注解指定能够接管的日期格局, 默认格局为 yyyy/MM/dd
1.3 如果在办法中须要指定这个参数的值必须在申请参数中有传递
@RequestParam 注解用于形容办法参数，用于定义参数规定
a. 办法参数变量的值，来自哪个申请参数
b. 办法参数变量是否能够不传值，例如 @RequestParam(required=true)
为什么办法的参数的变量 url 申请的参数名统一, 也用 @RequestParam 注解来形容?
因为晚期 JDK 中基本就拿不到办法中参数变量的名字, 即便办法的参数的变量 url 申请的参数名统一。
如果解决申请的办法的参数变量有两个, 得在 @RequestParam 注解的括号中增加 value=, 指定是给哪个变量赋值的
2. 在管制逻辑办法参数中基于 POJO 对象接管申请数据
2.1 当应用 pojo 对象封装申请参数信息时，申请中的参数名应与办法参数 pojo 对象中的 set 相干办法相匹配
3. 在管制逻辑办法参数中基于 Map 对象接管申请数据
3.1 应用 map 作为办法参数封装申请数据，默认是不能够的，数据是获取不到的，因为默认是封装响应数据的, 能够借助 @RequestParam 对 map 进行形容
4.rest 格调 url 中的参数
rest 格调: 软件架构编码格调(跨平台)
rest 格调 url 的定义:/path/{var1}/{var2}, 这里的{} 括起来的为变量
@PathVariable 注解形容办法的参数变量时，示意这个参数的变量的值来自 url 中{} 表达式给定的值