更新代码阅读文档

Finance-web/eladmin-system/src/main/java/me/zhengjie/modules/system/rest/PurchaseController.java

@@ -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);
     }
 }

源码阅读笔记.md

@@ -1,6 +1,6 @@
-## 二、目录与分类
+## 一、目录与分类
 
-1、分类框架
+### 1.1、主分类框架
 
 ​		在Spring Boot框架下，通常会将应用程序的功能划分为不同的模块或组件。根据您提供的信息，您的应用程序似乎被划分为了mnt、quartz、security和system这几个模块。
 
@@ -11,7 +11,7 @@
 
 ​		请注意，这些模块的具体功能和实现可能因应用程序的需求而有所不同。这只是根据您提供的信息给出的一种可能的解释。实际上，模块的划分和命名是根据具体的应用程序需求和架构设计来确定的。
 
-2、分类框架2
+### 1.2、次分类框架
 
 ​		在软件开发中，通常会将应用程序的逻辑划分为不同的层次，以便于维护和管理。其中，常见的一种架构风格是三层架构，即将应用程序的逻辑划分为表示层、业务逻辑层和数据访问层。
 
@@ -20,4 +20,47 @@
 - Domain（领域层）：表示应用程序的业务领域，包含了业务实体、值对象、服务等，是应用程序的核心。
 - Repository（数据访问层）：用于访问和管理应用程序的数据存储，可以是关系型数据库、NoSQL数据库、文件系统等。
 - Service（业务逻辑层）：用于实现应用程序的业务逻辑，协调和管理领域对象和数据访问对象之间的交互。
-- REST通常被视为表示层（Presentation Layer）的一种实现方式。表示层负责处理用户请求和响应，将用户的输入转化为对应的业务逻辑操作，并将结果返回给用户。
+- 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);
+}
+```
+