Http 响应结果可以是数据, 也可以是静态页面，首先创建前端页面 index.html
- html 代码
- 后台代码:
结果却发现, 页面未正确返回, http 响应把 “/index.html” 当做了 http 响应正文的数据，那 Spring MVC 如何才能识别出来 index.html 是⼀个静态页面, 并进行返回呢？
其实 @RestController = @Controller + @ResponseBody
- @Controller：用于标识这个类是一个控制器类，会接收并处理 Web 请求。
- @ResponseBody：定义返回的数据格式非 html，只返回一个数据
所以如果想返回视图的话, 只需要用 @Controller 就可以了
Spring Boot 的默认行为是当你返回一个静态文件时，它会自动从 resources/static/ 目录中查找对应的文件，所以返回 "/index.html"时，Spring Boot 会自动去 resources/static/ 目录下寻找对应的 index.html 文件。
我们上⾯讲到, @ResponseBody 表示返回数据.
@ResponseBody 既是类注解, 又是方法注解
- 如果作用在类上, 表示该类的所有方法, 返回的都是数据,
- 如果作用在方法上, 表示该方法返回的是数据.
也就是说:
- 如果类上有 @ResponseBody 就相当于在所有的方法上添加了 @ResponseBody 注解.
- 如果类上有 @RestController 就相当于在所有的方法上添加了 @ResponseBody 注解
如果⼀个类的方法里, 既有返回数据的, 又有返回页面的, 就把 @ResponseBody 注解添加到需要返回页面的方法上即可.
后端返回数据时, 如果数据中有 HTML 代码, 也会被浏览器解析
Spring MVC 也可以返回 JSON
Spring MVC 会根据我们方法的返回结果自动设置响应状态码, 程序员也可以手动指定状态码，状态码可以通过 Spring MVC 的内置对象 HttpServletResponse 提供的方法来进行设置
通过 Fiddler 来观察设置的结果:
我们通过设置 produces 属性的值, 设置响应的报头 Content-Type
运行程序, 浏览器响应结果如下:http://127.0.0.1:8080/returnJson2
通过 Fiddler 来观察设置的结果:
如果不设置 produces , 方法返回结果为 String 时, Spring MVC 默认返回类型是 text/html.
设置其他 Header 的话, 需要使用 Spring MVC 的内置对象 HttpServletResponse 提供的方法来进行设置
通过 Fiddler 来观察设置的结果:
结合上述内容, 我们可以做⼀些小案例，主要掌握知识点:
- 理解前后端交互过程
- 接口传参, 数据返回, 以及页面展示
需求: 输入两个整数, 点击 “点击相加” 按钮, 显示计算结果
- 创建 SpringBoot 项目: 引入 Spring Web 依赖, 把前端页面放在项目中
- 约定前后端交互接口：
接口定义：
请求参数:
响应数据:
2.1.1 服务器代码
2.1.2 调整前端页面代码
2.1.3 运行测试
启动服务, 运行并测试
Lombok 的核心功能是通过编译时注解生成常用的代码，例如 getter、setter、构造方法、toString、hashCode、equals 方法等，而不需要手动编写这些方法，简化 Java 的开发，下面来简单来学习下它的使用：
- 引入依赖
- 使用
lombok 通过⼀些注解的方式, 可以帮助我们消除⼀些冗长代码, 使代码看起来简洁⼀些。
这两段代码是等效的，@Data 注解会帮助我们自动生成⼀些方法, 包含 getter/setter, equals, toString 等，如果觉得 @Data 生成的方法太多了, lombok 也提供了⼀些更精细粒度的注解
上述引入 lombok 依赖, 需要去找 lombok 的坐标，接下来介绍更简单引入依赖的方式
- 安装插件 EditStarter, 重启 Idea
- 进入 Edit Starters 的编辑界⾯, 添加对应依赖即可.
注意:不是所有依赖都可以在这里添加的, 这个界面和 SpringBoot 创建项目界面⼀样，依赖不在这里的, 还需要去 Maven 仓库查找坐标, 添加依赖.
通过上面的练习, 我们学习了 Spring MVC 简单功能的开发, 但是我们也发现了⼀些问题：目前我们程序的代码有点 “杂乱”, 然而当前只是 “⼀点点功能” 的开发. 如果我们把整个项目功能完成呢，代码会更加的 “杂乱无章”
阿里开发手册中, 关于工程结构部分, 定义了常见工程的应用分层结构:
什么是应用分层？应用分层是⼀种软件开发设计思想, 它将应用程序分成 N 个层次, 这 N 个层次分别负责各自的职责, 多个层次之间协同提供完整的功能，根据项目的复杂度, 把项目分成三层, 四层或者更多层
为什么需要应用分层？在最开始的时候，为了让项目快速上线，我们通常是不考虑分层的.，但是随着业务越来越复杂，大量的代码混在⼀起，会出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动⼀处就牵⼀发而动全身等问题. 所以我们需要对应用进行分层
如何分层？咱们上⼀节中学习的 MVC, 就是把整体的系统分成了 Model， View 和 Controller三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是⼀种标准的软件分层架构。
目前现在更主流的开发方式是 “前后端分离” 的方式, 后端开发工程师不再需要关注前端的实现，所以对于 Java 后端开发者, 又有了⼀种新的分层架构: 把整体架构分为表现层、业务逻辑层和数据层. 这种分层方式也称之为"三层架构".
- 表现层: 表现层主要负责与用户进行交互，是用户直接看到并操作的部分。它接收用户输入的数据，并将处理后的数据结果展示给用户。
- 业务逻辑层: 业务逻辑层是系统的核心，负责实现具体的业务逻辑和规则。它处理表现层传递过来的请求，执行必要的计算或业务流程。
- 数据层: 数据访问层负责与数据库打交道，进行数据的持久化操作。
按照上面的层次划分, Spring MVC 站在后端开发人员的角度上, 也进行了支持, 把上面的代码划分为三个部分:
- 请求处理、响应数据：接收页面的请求，给页面响应数据.
- 逻辑处理：负责业务逻辑处理的代码.
- 数据访问：负责业务数据的维护操作，包括增、删、改、查等操作.
可以看到, 咱们前面的代码，我们将所有的代码堆砌在⼀起， 并不符合这种设计思想。
这三个部分, 在 Spring 的实现中, 均有体现:
- Controller：控制层。接收前端发送的请求，对请求进行处理，并响应数据。
- Service：业务逻辑层。处理具体的业务逻辑。
- Dao：数据访问层，也称为持久层。负责数据访问操作，包括数据的增、删、改、查.
- 先创建对应的包路径, 并把代码移到对应的目录
- 模型类：User
- 控制层: UserController
- 业务逻辑层: UserService
- 数据访问层: UserDao
- index.html
- 应用主程序：
此时当页面刷新或者关闭，数据都不会丢失。
- 降低层与层之间的依赖, 结构更加的明确, 利于各层逻辑的复用
- 开发人员可以只关注整个结构中的其中某⼀层, 极大地降低了维护成本和维护时间
- 可以很容易的用新的实现来替换原有层次的实现
- 有利于标准化
- 类名使用大驼峰风格
- 方法名、参数名、成员变量、局部变量统⼀使用小驼峰风格
- 包名统⼀使用小写，点分隔符之间有且仅有⼀个自然语义的英语单词.
常见命名命名风格介绍
- 大驼峰: 所有单词首字木都需要大写, 又叫帕斯卡命名法, 比如: UserController
- 小驼峰: 除了第⼀个单词，其他单词首字母大写,比如: userController
- 蛇形: 用下划线 (_) 作⽤单词间的分隔符, ⼀般小写, 又叫下划线命名法, 比如: user_controller
- 串形: 用短横线 (-) 作用单词间的分隔符, 又叫脊柱命名法，比如: user-controller
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/12860.html