一、项目框架构
本篇文章中主要记录了读取一个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的功能是限制令牌范围,否则就会陷入,你想使用登录页面需要先登录的诡异循环