当前位置: 首页 > 科技观察

基于RuoYi-Vue搭建健身会员管理系统,你学会了吗?

时间:2023-03-17 13:48:01 科技观察

最近在小伙伴们的强烈要求下学习了若一Vue,发现真的很好玩。它可以算是一个非常成熟的脚手架,我们可以基于它快速开发一个商业项目。有的朋友要宋哥帮你做这个项目。怎么说呢,如果看过vhr的视频,我觉得这个项目应该很容易看懂,基本上技术点都是一样的。不过最近刚好有空,不知道写什么博客,所以尝试带领小伙伴们以若一-Vue为脚手架,开发一个健身房的会员管理系统。对此感兴趣的可以点赞转发,这样这个系列才不会烂尾~另外,我假设大家已经在这个系列中做过vhr项目了,所以一些很基础的知识点我就不再重复了.一、现有动态菜单分析1.1两种方案动态菜单是用户登录后看到的菜单,不使用角色的用户登录成功后,会看到未使用的菜单项。如何实现这个动态菜单?总的来说,有两种不同的方案。在宋歌做过的项目中,这两种方案也都有使用。在这里,我将与您分享。1.1.1后端动态返回后端动态返回,这是我在微人里面采用的方案。在微人事中,与权限管理相关的表有五张,如下:hr表即用户表。用户登录成功后,可以查询用户的角色,然后根据用户角色查询用户可以操作的菜单(资源)。),然后将这些可操作的资源组织成一个JSON数据,返回给前端,前端根据JSON渲染相应的菜单。以微人员为例,我们返回的JSON数据格式如下:[{"id":2,"path":"/home","component":"Home","name":"员工信息","iconCls":"fafa-user-circle-o","children":[{"id":null,"path":"/emp/basic","component":"EmpBasic","name":"基本信息","iconCls":null,"children":[],"meta":{"keepAlive":false,"requireAuth":true}}],"meta":{"keepAlive":false,"requireAuth":true}}]这样的JSON可以在前端二次处理后使用。前端的二次处理主要是将组件属性的字符串值转换为对象。具体操作可以参考微人项目(具体:https://github.com/lenve/vhr/blob/master/vuehr/src/utils/utils.js),不再赘述这里。这种方式的一个好处是前端判断逻辑少,后端也不复杂。它只是一个SQL操作。前端拿到后端返回的菜单数据,稍微处理一下就可以直接使用了。这种方式的另一个好处是可以动态配置resource-role和user-role的关系,进而调整用户可以操作的资源(菜单)。1.1.2前端动态渲染的另一种方式是前端动态渲染。这样后端的工作比较轻松,前端的处理比较麻烦。松哥去年年底帮一家律所搭建管理系统,因为权限比较容易,我就采用了这种方式。这样,我直接在前端定义路由表中的所有页面,然后在meta属性中定义每个页面需要访问哪些角色,例如如下:[{"id":2,"path":"/home","component":Home,"name":"员工信息","iconCls":"fafa-user-circle-o","children":[{"id":null,"path":"/emp/basic","component":EmpBasic,"name":"基本信息","iconCls":null,"children":[],"meta":{"keepAlive":false,"requireAuth":true,"roles":['admin','user']}}],"meta":{"keepAlive":false,"requireAuth":true}}]这个定义表示当前登录用户需要具有管理员或用户角色,您可以访问EmpBasic组件。当然,这并不意味着我可以这样定义它。这个定义只是一个标记。在项目首页,我会遍历这个数组来动态渲染菜单,然后结合当前登录用户的角色和当前组件需要的角色来决定是否渲染当前组件对应的菜单项。在这种情况下,后台只需要在登录成功后返回当前用户的角色,剩下的交给前台。但是这种方式有一个缺点,就是菜单和角色的关系是硬编码在前端代码中的。如果以后要动态调整,会很不方便,可能需要改代码。尤其是大型项目,权限比较复杂的时候,调整起来比较麻烦,所以我一般推荐在一些简单的项目中使用这种方式。1.2菜单分析在若易-Vue中,采用了第一种方案,与vhr方案相同:服务端动态返回菜单信息,前端只是渲染。所以如果我们要自定义自己的项目菜单,非常容易,我们只需要了解本项目中的菜单表,然后直接修改菜单表即可。系统的菜单表是sys_menu,各个字段的含义如下:这个我就不多说了,作者已经把各个字段的意思写的很清楚了。对于一些新手朋友,我重点解释一下前端展示相关的一个字段:order_num:这个菜单项在前端页面展示的顺序,比如有用户管理和菜单管理在一级菜单系统管理,然后是用户管理和菜单管理,两个子项之间存在显示顺序问题,该字段就是用来解决这个问题的。path:这是前端的路由地址,可以简单理解为前端页面的跳转地址。假设系统管理菜单项的路径为system,系统管理下有一个子菜单logmanagement。日志管理的路径是log,在日志管理下有一个子菜单叫操作日志,操作日志的路径是operlog,所以最后前端访问操作日志的页面路由地址是/system/log/操作日志。component:这个是前端组件地址,因为前端vue文件是动态加载的,这个参数代表的是组件的名称。这些参数对于新手朋友来说可能不太容易理解。其他的参数大家看评论就明白是什么意思了,我就不再赘述了。看懂了手表,就可以直接入手,直接在手表上改。不过作者很贴心的提供了一个管理页面,如果懒得分析表格,也可以直接在系统管理->菜单管理中修改菜单。这个页面的操作比较简单,就不演示了。1.3代码分析我们来看一下服务器菜单相关的代码。菜单主要是层次问题,但是菜单的层次不会特别深。如果太深,前端不仅难以使用,而且不便展示。在vhr中,我假设菜单是三级的,然后用一个leftconnection找出所有的菜单信息。但是在这个项目中,菜单没有固定的层级,可以有N层,所以查询和vhr不一样,一起来看看吧。返回菜单数据的接口是org.javaboy.web.controller.system.SysLoginController#getRouters,我们来看一下:@GetMapping("getRouters")publicAjaxResultgetRouters(){LonguserId=SecurityUtils.getUserId();Listmenus=menuService.selectMenuTreeByUserId(userId);returnAjaxResult.success(menuService.buildMenus(menus));}具体的实现代码我就不说了,这里先说一下它的查询逻辑和核心操作,其实只有两步:menuService.selectMenuTreeByUserId方法查询所有当前菜单项。这里的查询思路是根据当前用户id,找到用户对应的菜单。查询时只查询类行为M和C的菜单项。M表示一个目录(即里面有子菜单),C表示一个菜单。全部查询完之后,遍历分类,把C作为某一个M的child。在松哥的vhr中,我直接用了一对多的思路来查询。获取查询后,无需再次处理。这里,是在得到query之后递归处理的。这一块的实现是不同的。做过vhr项目的小伙伴注意区分(也可以根据vhr的思路改一下这里的逻辑)。由于新查询到的菜单不满足前端渲染的要求,所以在menuService.buildMenus方法中,对刚刚查询到的List集合进行了再次处理。这里主要清空component、path等属性的值。就是这样。2.自定义菜单数据我们自己的健身会员的菜单会有所不同。我想自己重新定义它。根据上面第一节的分析,这里我将创建八个与健身会员管理系统相关的菜单。如下:收到系统原有功能的系统管理菜单。这个SQL脚本比较简单,可以在文末下载。简单截图给大家看看:根据第一节的分析,可以直接修改表格(也可以在菜单管理页面手动添加)。3.数据添加到自定义页面的后端,当然前端也添加了一个页面。component字段已经隐含了前端页面的地址,所以我们可以根据后端的component字段创建前端页面:每个.vue文件还没有写入内容,就一句话,类似到以下内容:稍后添加。好了,这样,前端vue登录成功后,就可以看到相应的页面了,页面也可以点击了。好了,这样一来,我们就初步实现了在这个项目上根据自己的需要定制自己的菜单。4.项目地址文末文末给出了一个项目地址,大家可以去看看。我会提交每篇文章的代码,逐步完善。你可以基于此看到一个项目的成长过程。现在明星是老粉了。https://github.com/lenve/tienchin