我们正在探秘各种比较火热的后台管理相关的开源项目,探秘结果将以系列文章的形式分享。希望你能在这些文章中学习别人的优点,也能看到别人的不足,进而可以提升自我的技术能力或技术态度,不论是提升了什么,只要你有收获即可。
“你若不离不弃,我必生死相依”,是一句非常痴情的话,也常被人化用于孩子的名字,寄托父母美好的期望。
今天要探的这个最火后台管理系统 RuoYi(若依),便是作者化用女儿的名字命名的项目。
项目介绍
RuoYi 主要在 Gitee
上维护,GitHub
也有同步项目,项目地址分别为:Gitee,GitHub。
截止 2022.10.18,该项目版本为 4.7.5
,在 Gitee 上收获点赞 3万2千5百 次,被"抄作业" 1万7千3百 次,还被 5千2百 人关注;在 GitHub 上则收获点赞 3千 次,被"抄作业" 988 次,还被 62 人关注。
如此高的热度,一定是有它的原因的。今天我们便来一探究竟。
看装修
用 IDEA 打开项目后,目录结构如图:
其中纯目录如下:
.github
:隐藏的 GitHub 相关配置文件,打开一看,可以看到作者的恰饭链接。果然恰饭得随时恰才行。bin
:里面有三个脚本clean.bat
、package.bat
、run.bat
,应该是清理、打包和运行脚本。doc
:里面有一个 word 文档,名为 《若依环境使用手册.docx》。
子项目目录则分为:
ruoyi-admin
:见名识义,我们推测项目应该管理相关功能模块ruoyi-common
:此项目推测为常用工具类、基础组件相关模块ruoyi-framework
:此项目应该为核心框架层面ruoyi-generator
:此项目可能是一种生成器工具ruoyi-quartz
:quartz
,照这个标准名字,推测此项目为定时器或定时任务相关模块ruoyi-system
:由于上面有framework
项目了,推测此项目为一些非业务功能的底层模块sql
:项目的数据库、表定义及初始化数据 sql 文件。
另外根目录下还有两个脚本 ry.bat
和 ry.sh
,由于上面 bin
目录中已有打包运行的整套脚本了,那么这两个脚本应该是 Windows 和 Linux 环境下的本地运行脚本。
从目录整体看的话,项目拆分中规中矩,但是在根目录和 bin
目录中都有脚本,显得有点凌乱,对于刚打开项目的我来说,我会不太明白这些脚本的用途。如果根目录中放脚本,是为了方便调试时更快的找到脚本,但脚本并不比 IDEA 本身直接 Run/Debug 方便;如果是为了验证 jar 的运行情况,那其实倒可以归整到 bin
目录中,再在里面区分为子目录 Release
和 Debug
。
但一千人眼里有一千个哈姆雷特,我和作者的眼里也会有不同的设计考虑,没有对错之分,也许只是我没有领会到他的目的。
看菜单
表面的目录结构看完了,要了解一个项目,还需要知道它是怎么运行起来的,在项目根目录中我们看到一个老朋友 pom.xml
,这个老朋友告诉我们:这个项目的包管理器是 Maven。那么打开这个 pom.xml
,我们就知道项目有些什么东西,地道不地道了,到底是不是正经厨子的作品。
pom.xml
配置项折叠后:
像图中一样,我们将 pom.xml
二级子项折叠后,可以看到子项之间的空行有多有少,可能作者没有代码洁癖,但强迫症患者则会表示看着真难受。
从第一部分项目基本信息中,如图:
可以看到,项目目前已是 4.7.5
版本,项目的网站地址为:http://www.ruoyi.vip。
第二部分的属性定义,如下图:
一般我们会将所有引用的包的版本信息都统一配置在 properties
,所以直接看属性配置,基本就能掌握所有引用的包的信息。
如图中所示,我们可以看到 RuoYi
项目中使用了并不太多的开源项目,正如项目描述中所说的一样“ 核心技术采用 Spring、MyBatis、Shiro,没有任何其它重度依赖”。确实如作者所说,这份硬菜里没有掺水。
我们在属性中,首先就看到了 Shiro
,项目整体的 RBAC 应该是基于 Shiro
构建的,接着,我们看到 thymeleaf-extras-shiro
,这个是一个将 Shiro
与 Thymeleaf
相结合的工具,也说明当前主项目不是前后端分离的开发模式,前端 Web 界面还是使用模板引擎 Thymeleaft
解析的。
再往下,我们看到 Druid
,说明作者采用了 Alibaba 的 Druid
作为数据库连接池,Alibaba 早就把此项目捐赠给了 Apache,所以如果你搜索 Druid
,最终一定会来到 Apache 的网站:https://druid.apache.org/。
然后我们发现属性中有一个 bitwalker.version
,这是项目中比较少见的一个组件,我们找一下对应的包,发现其为:eu.bitwalker:UserAgentUtils
,官网为:https://www.bitwalker.eu/software/user-agent-utils。官方介绍:“The user-agent-utils java library can be used to parse HTTP requests in real-time or to analyze log files and gather information about the user-agent”。意思就是说这个是用于处理浏览器 User-Agent 数据的工具组件。这个工具一般项目还是很少用的,不知道作者用它解决了什么问题。
再往下,看到有一个 kaptcha
,它所对应的是 com.github.penggle:kaptcha
,项目地址为 https://github.com/penggle/kaptcha。这是一个验证码生成工具组件,但是这个项目发布的包是 2015 年发布了,7 年啦,孩子都上小学了。这个组件已经存在两个安全漏洞了,个人建议最好替换为更好用更安全的组件。
下面是常规的用于 Restful API 文档生成的 swagger
。还有操作数据库的“半 ORM”框架 mybatis
,以及适配给 mybatis
用于分页查询的 pagehelper
,这两者经常一起搭配使用,用于数据库层面常见的分页查询业务。
在 pagehelper
下面,是我们绕不开的 json 工具组件,作者选用了 fastjson
。fastjson
作为 Alibaba 的一个开源组件,特点在于操作 API 简洁,一般情况下性能比较好,但这几年 fastjson
爆了很多安全漏洞,而且对于稍微复杂一点的 json 需求无法解决,各家企业都开始去除 fastjson
。建议为了项目的运行安全,如果可以的话,不要使用 fastjson
,推荐还是使用老牌的 com.fasterxml
家的 jackson
。
接着,properties
配置中倒数还有几个组件。第一个 oshi
比较有趣,这个对应的组件为: com.github.oshi:oshi-core
,这个组件项目地址为:https://github.com/oshi/oshi。这个组件用途是获取本地操作系统及硬件的信息,很好奇 RuoYi 用这个是实现了什么设计,道理上讲,不可能只是会了展示一下用户操作系统及硬件就完了。
剩下的 commons-io
是我们常用的 I/O 工具组件,多用来处理文件的读写或者 URL 数据的解析等,项目地址:https://github.com/apache/commons-io;而 commons-fileupload
是我们常用的文件上传工具组件,项目地址:https://github.com/apache/commons-fileupload;poi
则是常用的 Office 文件处理工具组件,作者选用了 OOXML
用于处理 Excel 表格文件,应该是有相应的业务需求,项目地址:https://github.com/apache/poi。
以上这几个都是 Apache 的开源项目,Apache 的项目不一定是最好用的,但质量一定是有基本保证的。
通过以上的分析过程,我们直接通过 properties
的定义就大概掌握了 RuoYi 项目所使用的开源组件的全貌。咦,等等,好像有一个很重要的遗漏了……是的,就是项目的核心框架 Spring Boot
遗漏了。我去……
我去 dependencies
看看,第一个就是它。如图:
原来作者没有将 Spring Boot 的版本定义到 properties
里,属实有点怪异。建议有洁癖的人,还是把这些版本统一定义,要不然真的难受。我们可以看到作者使用的 Spring Boot 版本为 2.5.14
,目前官方的最新版本为 2.7.4
,作者先用的版本还是比较新的。
试吃
分析了 pom.xml
中的开源组件情况,大致相当于了解了一家饭店的拿手菜以及常用的烹饪技法。接下来我们就要开始试吃这家店,对于项目而言,我们现在就要先把项目运行起来,看看它的实际效果如何。
我们去 ruoyi-admin
找一找,很快就可以找到启动类 RuoYiApplication
,如图:
我们可以看到,这里面除一行注释掉的无用代码外,有一行启动代码,然后还有一个使用 System.out.println
在控制台输出的 banner 字符画。作者还是很有情调的。但感觉有点不对呢,Spring Boot 不是提供了标准的 banner 输出方式吗?作者可能会不知道??我不信,赶紧找一找。果然有 resources
目录下发现 banner.txt
。如图:
果然作者是知道的,他就是想输出两个 banner!
不过,对于有洁癖的人来说,无用的代码就不要保留了,显得很不干净。
再细看一眼,咦,RuoYi 不是 Java 项目么,为啥这个一对大括号是前对齐呢,这不是 C# 的代码风格么?我去……
我去快捷键格式化一下,再把注释代码移除一下,如图:
舒服了。建议团队协作的开发者或者有洁癖的人,还是按语言特性对齐大括号,要不然风格不一致会让人感觉非常不适。
一切准备就绪,点击 Run
!翻滚吧,牛宝宝!!
果然,正如以前经历的万千情况一样,数据库无法连接,乖乖按文档先把数据库建好,再次点击 Run
!牛宝宝,翻滚吧!不行,翻滚前还要吐槽一下,为什么数据库的连接不能使用环境变量来动态指定,一定要写死成 localhost:3306
呢?算了,看看人家 3万 多的点赞,闭嘴吧。
牛宝宝,重新翻滚!
启动成功,控制台输出了作者的字符画,如图:
访问 http://localhost
,登录界面如图:
登录进入系统后,系统整体界面如图:
我们可以看到,整个系统功能模块主要分为:
系统管理
系统监控
系统工具
这些功能模块的进一步探秘,我们将在下篇继续。
小结
本篇,我们初探了 RuoYi 项目的大体结构以及主要依赖的开源组件。RuoYi 项目结构划分中规中矩,核心开源组件是常见的 Spring Boot
、Shiro
和 MyBatis
,工具组件使用的基本是 Apache 家族的,还有个别比较老旧的小组件。大厂家的组件安全性有保证,我们如果自己开发项目,尽量选择大厂家的开源组件,并尽量选择安全漏洞少的组件,可以有效减少产品交付后由于安全漏洞导致的版本升级、安全补丁发布等事情。
从 pom.xml
和 启动类,就可以看到作者的代码风格不好。建议项目开发中,我们要使用对应开发语言约定俗成的风格,并且我们还是要有点技术洁癖,不要在代码中用注释来保留那些没用的代码,毕竟 Git 就是帮我进行版本管理的工具。
下一篇,将继续展开 RuoYi 项目的功能模块,并逐一细细品尝各个功能。本篇就到这里,比心,❤。
更多文章,欢迎阅读我的博客阿呜的边程。
标签:项目,最火,RuoYi,开源,作者,组件,探秘,我们 From: https://www.cnblogs.com/dev2007/p/16805245.html