# rain-drop

**Repository Path**: yt220600/rain-drop

## Basic Information

- **Project Name**: rain-drop
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-12-21
- **Last Updated**: 2024-06-30

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 🍰RainDrop

一个基于RBAC的权限管理系统，这种系统烂大街了，但是我有造轮子强迫症，作为一个程序员，一个东西你会用和你会写是两回事😉

RainDrop是后端部分

🍺所用技术：Jdk21，springboot3.3.0，maven3.9.6，mysql8，redis

## 1 项目结构

🧀项目结构如下

```java
raindrop-parent:父模块，聚合工程，管理项目信息以及一些依赖版本
    |----------->raindrop-common:引入了公共依赖，并抽取了一些工具类和公共代码
    	|----------->annos:统一存放项目中使用的注解
        |----------->enums:统一存放项目中使用的枚举
        |----------->exception:统一异常处理的相关代码
        |----------->utils:一些自定义工具类
        |----------->web:web服务公共代码
    |----------->raindrop-core:系统核心模块，包含一些组件和配置，主要包含下面几个核心包
        |----------->auth:基于servlet规范的过滤器实现的自定义授权认证模块
        |----------->cache:定义了缓存操作接口并集成了几个常见缓存组件，在配置文件可以指定使用的组件
        |----------->storage:定义了文件操作接口并集成了几个常见文件存储组件，在配置文件可以指定使用的组件
        |----------->mp:本项目使用了mybatisplus，所以mp是mybatisplus的相关包
        |----------->mvc:本项目使用了springmvc，所以mvc是springmvc的相关包
        |----------->swagger:接口文档相关包
        |----------->web:本系统自带功能的CRUD代码和其他相关代码，跟业务代码分开
    |----------->raindrop-system:业务模块，使用者可以在该模块写业务代码
```



## 2 启动项目

必须：

* 使用项目根目录下的doc文件夹下的sql文件初始化数据库
* 然后修改`raindrop-system`模块的配置文件中的数据库连接信息
* 如果Maven依赖没有完全下载，需要下载直到pom.xml没有爆红，本项目依赖可以直接在阿里云仓库下载

可选：

* 本项目依赖的缓存组件默认是基于JVM内存的`Caffeine`，因此可以不用启动Redis或其他缓存组件
* 如果想要更换缓存为Redis，修改配置文件的`drop.cache.type`为redis即可

运行业务模块下的RainDropApplication类，即可启动该SpringBoot项目

## 3 一些计划

- [x] RBAC基础功能
- [x] 字典管理
- [ ] 数据库管理模块
- [ ] 在线用户
- [ ] 邮件管理
- [ ] 定时任务
- [ ] 登录日志
- [ ] 操作日志
- [ ] 错误日志
- [ ] 代码生成
- [x] 文件系统
- [X] 接口文档
- [ ] 国际化
- [ ] 组织关系管理
- [ ] 服务器状态信息
- [ ] 流程管理
- [ ] 支付管理
- [ ] 单点登录



## 4 使用协议

- 开源协议：MIT



# 🍍规范

本项目定义了一些规范，为了协同前后端进行开发

俗话说约定大于配置，约定本身没什么技术含量，好的约定可以避免很多开发问题

当然，这个约定只是基于本人的开发习惯，使用者可以不必遵守



## 1 实体类

一个实体类对应了数据库的一张表，统一放在po包下

* 实体类都应该继承`PersistenceModel`类，PersistenceModel类有五个字段id、createTime、createBy、updateTime、updateBy
* 如果实体类是树形结构，应该继承`BaseTree`类，BaseTree继承了PersistenceModel类，并在PersistenceModel的基础上引入了两个字段pid、children分别表示上级数据id和所有子数据



## 2 请求

对应从前端到后端的请求数据，统一放在req包下

* 接口应该用类来接收，并且使用`@ModelAttribute`修饰
* 后端接收的类应该以`Req`结尾，如果是分页请求，则该类应该继承`PageReq`
* 如果可以直接使用持久层的实体类作为接口参数，则可以忽略上一条



## 3 响应

对应从后端到前端的响应数据，统一放在resp包下

* 普通CRUD接口的响应应该统一返回`R`对象
* 本项目做了处理，如果返回类型不是`Void`并且也不是`R`，就将返回数据封装成R在写入响应体

* 不管是直接返回的数据，还是包了一层R再返回的数据，类名应该统一以`Resp`结尾
* 如果可以直接使用持久层的实体类作为接口返回数据，则可以忽略上一条



## 4 业务层

service层的类

* 接口名称应该是接口对应实体类+Service的格式

  比如用户模块实体类是`SysUser`，则对应的service层接口应该是`SysUserService`

* 接口实现类应该以`ServiceI`结尾或者`ServiceImpl`结尾，并以对应实体类作为前缀

  比如用户模块service层接口的实现类应该是`SysUserServiceI`或者`SysUserServiceImpl`

* 如果一个service接口有多个实现类，则其实现类可以根据具体的实现命名

  比如基于微信登录的用户模块实现类可以是`WxSysUserServiceI`，基于手机登录的可以是`PhoneSysUserServiceI`

* 如果一个功能点耦合了多个模块，则该功能点的代码建议放在主模块的service类中

  比如根据用户id查询角色的功能点，涉及用户模块和角色模块，先根据id查询出用户信息再根据用户查出角色，最后组合成resp数据响应，可以看出该功能点是以用户为主，所有角色模块是主模块