forked from knyin/finance
67 lines
5.1 KiB
Markdown
67 lines
5.1 KiB
Markdown
## 一、目录与分类
|
||
|
||
### 1.1、主分类框架
|
||
|
||
在Spring Boot框架下，通常会将应用程序的功能划分为不同的模块或组件。根据您提供的信息，您的应用程序似乎被划分为了mnt、quartz、security和system这几个模块。
|
||
|
||
- mnt模块：可能是指"maintenance"（维护）模块，用于处理应用程序的维护相关功能，如日志记录、监控和性能优化等。
|
||
- quartz模块：可能是指Quartz调度框架相关的模块，Quartz是一个功能强大的作业调度器，用于在特定的时间点或按照一定的规则执行任务。
|
||
- security模块：可能是指安全模块，用于处理应用程序的安全相关功能，如用户认证、授权、权限管理等。
|
||
- system模块：可能是指系统模块，用于处理应用程序的系统级功能，如配置管理、异常处理、国际化等。
|
||
|
||
请注意，这些模块的具体功能和实现可能因应用程序的需求而有所不同。这只是根据您提供的信息给出的一种可能的解释。实际上，模块的划分和命名是根据具体的应用程序需求和架构设计来确定的。
|
||
|
||
### 1.2、次分类框架
|
||
|
||
在软件开发中，通常会将应用程序的逻辑划分为不同的层次，以便于维护和管理。其中，常见的一种架构风格是三层架构，即将应用程序的逻辑划分为表示层、业务逻辑层和数据访问层。
|
||
|
||
在这种架构风格中，通常会使用以下术语来描述不同的层次：
|
||
|
||
- Domain（领域层）：表示应用程序的业务领域，包含了业务实体、值对象、服务等，是应用程序的核心。
|
||
- 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);
|
||
}
|
||
```
|
||
|