Airboot-SaaS

多租户动态数据源版本现已重磅发布！请前往 Airboot-SaaS-DataSource 。

注意：如需非多租户版本请移步至 Airboot 。

---

介绍

Airboot-SaaS是一个轻量级通用多租户管理系统。在主要功能上将与 Airboot 保持一致，但是会兼容多租户的模式。

• 前端使用 Vue + Element
• 后端使用 Spring Boot + Mybatis-Plus
• 缓存使用 Redis，数据库使用 MySQL
• 登录验证使用 JWT，支持切换唯一登录
• 使用代码生成器可以一键生成前后端代码

本系统初期基于 若依（RuoYi-Vue） 二次开发，启动开发时对应的若依版本在2.2至2.3之间，之后的功能路线与若依不同，基本没有再合并若依的更新。

若依本身是一个优秀的开源项目，我根据个人开发习惯做了一些架构和细节上的改动，其中后端改动较大，前端改动较小，UI风格没有变化（若依也是直接采用了vue-admin-element），总的来说也谈不上什么优化，欢迎有类似开发习惯的小伙伴们尝试使用。

主要改动如下：

1. 将Mybatis替换为 Mybatis-Plus ，简化了Mapper代码；
2. 去掉了字典管理功能，全部改为枚举实现。这东西见仁见智，只是我个人更习惯用枚举，没有绝对的好坏。非要说原因的话，请看：为什么去掉字典管理？
3. 去掉了较重的Spring-Security，改为自定义拦截器实现，原因请看：为什么去掉Spring-Security？
4. 添加多租户支持，采用【共享数据库，共享数据表】的模式（即通过表内的tenant_id来区分租户）。后期可能会再添加【共享数据库，独立Schema】的模式，以适应不同需求；
5. 其他细节改动，如代码风格、框架配置、工具类封装、代码生成等等。

详细的使用文档会在近期放出。

---

如何开始

环境准备

• JDK 8+
• Node.js 10+
• MySQL 5.5+
• Redis

后端启动

1. 在MySQL中新建一个数据库（字符集utf8mb4），随后将airboot-server/sql/init.sql导入数据库中建表；
2. 检查application.yml及application-dev.yml中各项配置，尤其MySQL和Redis的链接地址；
3. 在IDE中启动开发调试，观察日志输出，启动成功后会出现Airboot Server启动成功！的提示。

前端启动

在airboot-web目录下打开命令行：

# 使用淘宝源来加快下载速度
npm config set registry http://registry.npm.taobao.org/

# 解决node-sass可能下载出错的问题
npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/

# 安装依赖
npm install

# 启动服务
npm run dev

启动成功后浏览器访问 http://localhost/

管理员账号 admin，密码 admin123

---

演示截图

---

FAQ

为什么去掉字典管理？

1. 字典看起来灵活，能够随时新增和修改，但如果没有业务关联就是没有意义的数据。而如果想要做业务关联，大部分情况下还是要去修改代码的，字典并没有减轻你的工作。比如在 RuoYi-Vue 的源代码中，虽然字典定义了0是正常状态，1是停用状态，但依然要在代码里用常量类 UserConstants.java 来为0和1赋予具体的业务含义，然后再拿来比对用户或部门的状态等，其实是比添加和使用枚举更繁琐了一点。

2. 我认为最适合使用字典的是像新闻类别这样的数据，只要我预先写好代码，就可以动态增改新闻类别，因为处理逻辑都是一样的。但要注意，像这样的字典，恰恰不应该放进像字典管理这样统一的功能中。原因如下：

   1. 首先从权限上就不好控制，我想授权一个人管理新闻类别，但不想让他看到其他的字典，这是很正常的权限需求，但如果所有字典数据全都放在字典管理里，这个权限就很难控制，RuoYi-Vue 并没有在字典管理上实现这种权限细分，而如果你想自己实现也是很繁琐的。
   2. 其次，我的新闻类别不一定是只要有字典名称和字典值这两个字段就能满足了，我可能还需要其他属性，但我总不能去给字典表随便添加字段吧？

   所以正确的做法是：单独建一张新闻类别表，单独加一个新闻类别管理功能，这样不但业务清晰，也便于管理。

3. 如果我们在系统中大量使用字典，就意味着我们在所有用到字典数据的地方都需要去后端获取，否则用户会无法使用查询条件，列表数据里的字典值也无法转义。这在请求量少的时候没多大问题，但如果请求非常多，对数据库的压力是显而易见的。可如果把字典数据拉到缓存里，又会面临缓存和数据库双写的问题。或者我们可以设置一个按钮来手动刷新缓存，但也会存在忘记刷新的风险。

   而如果我们使用枚举，这些问题都是不会存在的。

4. 字典管理如果想要做的完善，还需要考虑很多细节。比如是否需要对修改和删除进行控制，如果不控制，那字典值修改或删除后，使用到此字典值的旧数据怎么办？如果要控制，那就需要遍历可能用到字典值的数据表，并作出相应处理。在 RuoYi-Vue 的源代码中是直接就可以修改和删除的，并没有做控制处理，而如果我们自己实现的话也需要花很多时间和精力。相比之下枚举就不存在这样的问题。

综上所述，我并非反对使用字典，而是认为使用字典一定要有合适的情况和明确的目的（比如单独的新闻类别管理是合适且明确的），像统一的字典管理其实是没有必要的。

为什么去掉Spring-Security？

Spring-Security的确是功能强大的权限框架，但一方面是较重，不符合Airboot-SaaS轻量级的理念。另一方面，如果想要用好Spring-Security的强大功能，需要对其有一定的熟练度，这无疑会给想使用Airboot-SaaS进行二次开发的人设置了门槛，所以我将其替换成了更易于理解和改造的自定义拦截器。

我个人认为，权限这个东西，说通用也通用，说不通用也不通用，很多公司在权限上其实都会有自己的特殊需求。除非你的目的是做一个庞大且复杂的管理系统，否则没有必要考虑用Spring-Security。

为什么本项目中的枚举几乎都是中文？

1. 增加了代码的可读性，尤其对于业务类枚举来说（在某些专业领域的业务中更是如此），不必再绞尽脑汁想合适的专业英文翻译或拼音简写。除非你所在的项目团队有外国开发人员，或者你的开发/部署环境不支持中文字符；
2. 中文枚举可以直接返回给前端作为字符串展示，大部分情况下不需要再次翻译给用户看。

综上所述，我一直推荐使用中文来命名业务相关的枚举、常量或局部变量，但对于类似实体类的属性等不推荐使用中文，因为会导致getter和setter的方法名看起来很怪。