更新代码阅读文档
parent
06dcf73ffb
commit
0f3792c530
|
|
@ -38,16 +38,16 @@ import me.zhengjie.modules.system.service.dto.PurchaseDto;
|
|||
*
|
||||
**/
|
||||
@RestController
|
||||
@RequiredArgsConstructor
|
||||
@RequiredArgsConstructor // 注解是Lombok库提供的注解，用于自动生成构造方法，这里用于生成带有purchaseService参数的构造方法
|
||||
@Api(tags = "经费支出管理")
|
||||
@RequestMapping("/api/purchase")
|
||||
@RequestMapping("/api/purchase") // 控制器类的请求路径为"/api/purchase"
|
||||
public class PurchaseController {
|
||||
|
||||
private final PurchaseService purchaseService;
|
||||
|
||||
@Log("导出数据")
|
||||
@ApiOperation("导出数据")
|
||||
@GetMapping(value = "/download")
|
||||
@GetMapping(value = "/download") // 对应HTTP的GET请求，请求路径为"/download"
|
||||
@PreAuthorize("@el.check('purchase:list')")
|
||||
public void exportPurchase(HttpServletResponse response, PurchaseQueryCriteria criteria) throws IOException {
|
||||
purchaseService.download(purchaseService.queryAll(criteria), response);
|
||||
|
|
@ -85,6 +85,7 @@ public class PurchaseController {
|
|||
@PreAuthorize("@el.check('purchase:del')")
|
||||
public ResponseEntity<Object> deletePurchase(@RequestBody Long[] ids) {
|
||||
purchaseService.deleteAll(ids);
|
||||
// 返回一个HTTP状态码为200（OK）的响应
|
||||
return new ResponseEntity<>(HttpStatus.OK);
|
||||
}
|
||||
}
|
||||
49
源码阅读笔记.md
49
源码阅读笔记.md
|
|
@ -1,6 +1,6 @@
|
|||
## 二、目录与分类
|
||||
## 一、目录与分类
|
||||
|
||||
1、分类框架
|
||||
### 1.1、主分类框架
|
||||
|
||||
在Spring Boot框架下，通常会将应用程序的功能划分为不同的模块或组件。根据您提供的信息，您的应用程序似乎被划分为了mnt、quartz、security和system这几个模块。
|
||||
|
||||
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
请注意，这些模块的具体功能和实现可能因应用程序的需求而有所不同。这只是根据您提供的信息给出的一种可能的解释。实际上，模块的划分和命名是根据具体的应用程序需求和架构设计来确定的。
|
||||
|
||||
2、分类框架2
|
||||
### 1.2、次分类框架
|
||||
|
||||
在软件开发中，通常会将应用程序的逻辑划分为不同的层次，以便于维护和管理。其中，常见的一种架构风格是三层架构，即将应用程序的逻辑划分为表示层、业务逻辑层和数据访问层。
|
||||
|
||||
|
|
@ -21,3 +21,46 @@
|
|||
- Repository（数据访问层）：用于访问和管理应用程序的数据存储，可以是关系型数据库、NoSQL数据库、文件系统等。
|
||||
- Service（业务逻辑层）：用于实现应用程序的业务逻辑，协调和管理领域对象和数据访问对象之间的交互。
|
||||
- REST通常被视为表示层（Presentation Layer）的一种实现方式。表示层负责处理用户请求和响应，将用户的输入转化为对应的业务逻辑操作，并将结果返回给用户。
|
||||
|
||||
## 二、数据交互
|
||||
|
||||
本质上，web的业务代码本质上就是前端请求数据后端查询数据库，中间层对业务和权限等进行处理和校验。所以对于一个购买功能的实现需要分为三个`java`文件完成：
|
||||
|
||||
```java
|
||||
PurchaseController.java // 负责处理前端页面的请求
|
||||
PurchaseServices.java // 中间层，对业务数据进行处理或者权限的校验
|
||||
Purchase.java // 负责处理和数据库的处理
|
||||
```
|
||||
|
||||
实际上，`eladmin`框架分的要更加细一点。前端的`Controller`主要对前端页面进行交互和处理。`Controller`调用`Services`对数据进行具体的操作。由于面向对象的设计，`Service`往往是接口，实现实际上是`ServicesImpl`完成的。由于数据库类和普通数据类存在差异，所以产生了`domain`下面的操作数据库的类。如`Purchase.java`就是高度抽象的数据库操作类。`PurchaseMapper`实现从`Purchase`映射数据到普通数据类`PurchaseDto`, 总结如下：
|
||||
|
||||
```java
|
||||
Purchase.java // 对数据库的抽象操作
|
||||
PurchaseController.java // 前端处理类，负责处理前端的数据请求处理
|
||||
PurchaseServices.java // 服务接口类，帮助PurchaseController类完成具体的后台数据操作
|
||||
PurchaseDto.java // 将数据库操作类的数据映射到普通类，是数据的容器
|
||||
PurchaseMapper.java // 将Purchase映射到PurchaseDto
|
||||
PurchaseServicesImpl.java // PurchaseServices接口类的实现
|
||||
PurchaseRepository.java // 实现对数据库的CRUD操作以及动态查询操作如findById、findAll等
|
||||
PurchaseQueryCriteria.java // Purchase查询条件类，用于前端数据查询的数据结构
|
||||
```
|
||||
|
||||
所以，上面的代码看着东西很多，实际上就是因为被拆分为太多了功能(为了解耦和复用)，产生了非常多的`java`文件。所以不得不吐槽这个过度封装，感觉一个很简单的功能写出这么多的代码。或许这种写法实在太啰嗦，所以才产生了代码生成器功能。
|
||||
|
||||
三、代码解析
|
||||
|
||||
```java
|
||||
// 使用Spring Boot框架编写的RESTful API接口方法，用于删除经费支出
|
||||
@DeleteMapping // 注解表示这个方法对应HTTP的DELETE请求
|
||||
@Log("删除经费支出") // 执行前会记录一条日志，日志内容为"删除经费支出"
|
||||
@ApiOperation("删除经费支出") // 接口文档描述为"删除经费支出"
|
||||
@PreAuthorize("@el.check('purchase:del')") // 执行前会进行权限检查，只有拥有"purchase:del"权限的用户才能调用这个方法
|
||||
// 接收一个请求体为Long类型数组的参数，参数名为ids
|
||||
public ResponseEntity<Object> deletePurchase(@RequestBody Long[] ids) {
|
||||
// 调用purchaseService的deleteAll方法，传入ids参数进行删除操作
|
||||
purchaseService.deleteAll(ids);
|
||||
// // 返回一个HTTP状态码为200（OK）的响应
|
||||
return new ResponseEntity<>(HttpStatus.OK);
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue