一、项目框架构
本篇文章中主要记录了读取一个springboot文件时在其中不同部分的具体作用下面是框架构成
整体文件的分布如上图，下面为分支部分简介
big-events
├─ big-event
│ ├─ pom.xml（主要的配置文件，需要用到的所有jar包可以通过这个文件导入）不写
│ ├─ 大事件接口文档.md（存放系统开发需求的文档）
│ └─ src
│ └─ main
│ ├─ resources
│ │ ├─ application.yml（全局信息配置，例如数据库名称密码，端口号，命名规则）
│ │ └─ com
│ │ └─ itheima
│ │ └─ mapper
│ │ └─ ArticleMapper.xml（对mapper文件中的函数进行注册说明）
│ └─ java
│ └─ com
│ └─ itheima
│ ├─ BigEventApplication.java（启动类）
│ ├─ validation （验证，确保了数据的准确性和完整
│ ├─ utils (工具包)
│ ├─ service（在此层做相应的业务逻辑处理）
│ │ └─ impl (impl是implement的简写，换言之，放置的应该是接口的实现类)
│ ├─ pojo（Plain Old Java Object）文件夹通常用于存放模型类（也称为实体类
│ ├─ mapper （从数据库中检索数据、执行插入、更新和删除操作
│ ├─ interceptors（令牌验证）
│ ├─ exception （报错信息设置）
│ ├─ controller（接收请求、处理业务逻辑，并返回响应给客户端
│ ├─ config（网页验证
└─ anno （全名annotation注解）
二、分支梳理
下面就是一个个的把上面的文件夹解释一遍
1.md文档
md文档在前后端配合工作的时候向双方阐明必要的参数，保证双方在开发过程中有一致性，下面是一个示例
md文档的组成分为三个部分，其中基本信息中的请求方式和请求类型会在Controller和Service文件中进行定义，请求参数则表示前端回传的请参数种类，在编写接口类的时候需要注意匹配
相应数据则是为了保证在前段进行测试时，后端能有特定的返回值，方便更好的实现项目逻辑，其中报错信息将会定义在exception类中
2.application.yml
全局的信息配置文件，对接口，数据等等部分进行模式设置和信息设置，下面是一个简单的示例
特别的地方是，有些后端的程序需要多模式运行，或者是在不同情况下用不同的端口，此时就会涉及到多种模式的配置，为了让程序在其他设备上更加快捷的运行，yml文件支持多模式的配置定义，可以通过单文件和多文件进行
3.BigEventApplication.java
SpringBoot项目配置的启动类主要用来启动本地服务器端口，启动后我们就可以通过浏览器或者Postman这一类的测试软件对后端的接口进行测试，无需过多前段的代码。可以理解为一个后端程序的main函数，@SpringBootApplication后面的定义意为移动注册函数的扫描包
4.Service
Service（服务接口）
定义业务逻辑：
Service层是应用程序的业务逻辑层，它定义了应用程序的操作和业务规则。这些操作通常涉及数据的创建、读取、更新和删除（CRUD）以及更复杂的业务流程。接口抽象：
Service接口提供了一组抽象的方法声明，这些方法描述了可以执行的业务操作，而不需要指定这些操作的具体实现细节。事务管理：
Service层是进行事务管理的理想位置，可以使用Spring的@Transactional注解来声明事务的边界，确保数据的一致性和完整性。跨层调用：
Service层的方法可以被Controller层直接调用，这样Controller就不需要关心业务逻辑的具体实现，只需要关注如何处理用户请求和响应。---------------------------------------------------------------------------------------------------------------------------------------------------------
参考下面这张图片，简单来说编写Service时只需要考虑三件事，传入值，传出值，是否需要Spring aop框架引入（这个项目没有涉及Aop，仅做参考）
5.POJO
POJO（Plain Old Java Object）文件夹通常用于存放模型类（也称为实体类或领域对象），这些类是应用程序的核心组成部分，用于表示业务数据和规则，大白话就是定义类
以下是POJO文件夹的一些主要用途：
数据模型表示：POJO类通常映射数据库中的表，每个类代表一个实体，类的属性对应表中的列。这样设计的目的是为了简化数据库操作，使得数据的CRUD操作更加直观和方便。（数据验证也会在这里操作）
业务逻辑封装：除了数据模型的表示，POJO类还可以包含一些业务逻辑，如验证规则、计算方法等。（就是类的函数）
DTO和VO的区分：在一些复杂的应用中，可能会有专门的数据传输对象（DTO）和视图对象（VO）与POJO类并存。DTO用于在层与层之间传递数据，而VO用于展示层的数据展示。这样的分层设计有助于清晰地划分系统的不同职责。
依赖注入：Spring框架支持依赖注入，这意味着你可以在POJO类中注入其他Spring管理的bean，从而实现松耦合的设计。
6.Mapper
数据访问层（DAO）：
Mapper通常是指数据访问对象，它是数据访问层（Data Access Object）的一部分。Mapper的职责是从数据库中检索数据、执行插入、更新和删除操作。接口和注解：在Spring Boot中，
Mapper接口通常使用MyBatis或Spring Data JPA等ORM框架来实现。这些框架提供了注解（如@Select,@Insert,@Update,@Delete）来定义SQL操作，这些注解将方法与数据库中的SQL语句映射起来。（复杂的处理过程有时需要借助xml文件进行进一步定义）易于测试和维护：
Mapper接口的定义清晰地表达了数据访问的需求，这使得单元测试更加容易实现，同时也便于维护和重构。
将数据库的语句用注解或者xml文件的形式绑定到函数上，就可以实现对数据库的操作！
7.Contorller
Controller（控制器）
Web层：
Controller是Spring MVC中的一个组件，它负责处理来自客户端的HTTP请求。Controller接收请求、处理业务逻辑，并返回响应给客户端。请求映射：
Controller类中的方法是请求映射的入口点，通过使用注解（如@RequestMapping,@GetMapping,@PostMapping等）来定义哪些HTTP请求应该由特定的方法来处理。业务逻辑处理：
Controller中的方法通常包含业务逻辑的处理，它们可以调用服务层（Service Layer）中的方法来执行实际的业务操作。视图渲染：对于需要返回视图的请求，
Controller负责选择适当的视图模板，并传递必要的数据给视图。在RESTful服务中，Controller则负责返回JSON、XML等格式的数据。参数绑定：
Controller方法可以使用Spring的参数绑定机制来接收来自请求的参数，包括路径变量、查询参数、表单数据等。异常处理：
Controller还可以通过@ControllerAdvice和@ExceptionHandler注解来全局处理控制器层抛出的异常，提供统一的错误处理和错误信息返回。总的来说，controller层需要完成的操作包括：明确请求类型，检证输入函数，返回相应参数，按照md文档要求设置函数的访问路径
8.Anno和validation
这两个类可以理解为“定制注解”，普通的工具类中提供的验证操作。（看看就行，需要再查
//下面这个定义了一个验证，验证String必须为“已发布”或者是“草稿”
9.其他工具
前面没有提到的两个部分分别是Util工具包和涉及网页登录令牌检验的包
其中每个网页在设计是需要用到的特定工具包统一放在Util中，方便我们进行管理
而网页令牌则是在登录之前申请一个令牌，保证没有登录的用户不可以访问其他的页面
Interceptors 的主要功能：
预处理：在Controller处理请求之前，可以执行一些通用逻辑，如权限验证、日志记录、请求参数的预处理等。
后处理：在Controller处理请求之后，但在视图被渲染之前，可以执行一些通用逻辑，如添加额外的模型数据、处理异常等。
请求完成：在整个请求结束之后，无论成功还是发生异常，都可以执行一些通用逻辑，如清理资源、记录请求结束时间等。
Config的功能是限制令牌范围，否则就会陷入，你想使用登录页面需要先登录的诡异循环
700
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
