高校实训室预约系统的设计与实现
2023-09-26周科艳周志坚
周科艳,周志坚
(无锡商业职业技术学院 经济管理学院,江苏 无锡 214000)
目前,高校实训室管理主要依靠管理员手工安排实训室工位.随着校企合作、举办技能竞赛等需求的出现,实训室不仅需要对本校学生开放,也需要对校外人员开放[1].如果实训室管理人员手工审核校外人员信息,会出现一些问题,如用户身份核验信息录入时可能会出现数据错误;用户无法及时反馈使用过程中的问题和建议;管理员只能调用自己所管辖的实训室资源,无法利用其他的实训室资源等.为此,本文以校园网为依托,采用前后端分离开发技术,设计了一套实训室预约系统,以期实现实训室资源的优化配置,提高实训室的利用率.
1 实训室预约系统设计
1.1 系统结构
系统的结构分为前端和后端两部分.前端使用微信小程序实现,运行在微信平台上,为用户提供预约、身份验证等操作界面;后端主要采用SpringBoot框架处理用户请求并响应结果[2].系统结构示意图见图1.
图1 系统结构示意图
后端除了使用Spring Boot框架构建业务系统外,还涉及到Docker容器、MySql数据库、Redis缓存服务和FastJson等技术.Spring Boot框架用于快速构建业务后端服务系统.MySql数据库是一种关系型数据库管理系统,在本文设计的系统中用来存储系统所需要的各项数据.Redis是一个开源的内存数据结构存储系统,在本文设计的系统中使用它的缓存功能来验证token信息,以提高系统的性能.前后端数据之间的通信采用JSON 格式,本系统使用FastJson对JSON 格式的数据进行解析和打包.当系统后端服务开发完毕后,将服务打包为jar文件,单独部署到Docker 容器中.系统运行所需要的数据库服务和缓存服务也可以通过Docker部署,以提高系统的性能和易用性.
1.2 数据库设计
在整个系统中,涉及到的数据表有6个.第一个是实训室信息表,见表1,主要记录实训室的名称、地址、工位数目和其他相关信息.实训室的名称和地址可展示在预约用户的操作界面上,实训室的工位数目表示该实训室可提供的工位.
表1 实训室信息表
第二个是用户信息表,见表2,主要记录用户姓名、用户类型等相关信息.校内的学生和教工信息可以从学校的相关系统中导出,校外人员信息可以在预约过程中实时生成.username字段取值约定为:教工为工号,学生为学号,校外人员留空.major_id为教工和学生所属专业的编号;对于校外人员,该编号设置为空.由于采用微信小程序验证用户信息,故还需要记录用户在小程序中的标识,即openid信息.为保证系统安全性,openid需要加密后保存.
表2 用户信息表
第三个是专业信息表,见表3,主要记录各实训室涉及到的专业.
表3 专业信息表
由于实训室信息和专业信息是多对多的关系,因此需要第四个数据表来维护这种关系,见表4.
表4 专业-实训室对应信息表
这些数据的维护由系统管理员完成,需要在使用系统前进行初始化.
第五个是预约记录表,见表5,主要记录用户标识、实训室标识、预约日期、预约时段、预约二维码等.本系统支持当前用户为其他用户预约实训室,user_id 字段记录实际使用实训室的用户编号,prac_user_id字段记录小程序用户编号,若只为自己预约,两个字段的值保持一致.status字段用于标志校外用户的预约状态,status为1表示预约待审核,当系统管理员审核完成后,status置位0,同时生成二维码.实训室一旦预约成功,用户可以在微信小程序中查看自己预约成功的二维码,该二维码用于扫码入校和进入实训室.
表5 实训室预约记录表
第六个是反馈记录表,用于记录用户对实训室的反馈情况,见表6,如用户标识、实训室标识、反馈日期、反馈内容等.
表6 实训室反馈记录表
1.3 功能设计
本系统主要实现如下功能:实训室使用者可以使用微信小程序进行实训室预约、查看预约结果和反馈实训室存在的问题;实训室管理员可以通过后端实时了解实训室的工位安排情况,并通过身份验证机制合理分配实训室工位.
实现上述功能需要两个模块.一是用户身份核验模块,流程见图2.对于校内人员,由于系统管理员在后台已将数据导入到用户信息表中,直接使用微信注册的手机号授权登录即可;若手机授权无法登录,说明手机号不在用户信息表中,表示该用户为第一次使用本系统的校外人员,界面将转入个人信息维护界面.二是预约模块,预约流程见图3.用户在预约界面提交实训室信息和预约信息后,即可完成预约.
图2 身份核验流程
图3 预约流程
在预约模块中,最核心的内容是预约逻辑的实现.使用本系统,既可以本人预约,也可以替用户信息表中的其他用户预约,还可以进行批量用户预约,这样就可以大大方便管理人员操作.
为保证系统的安全性,不同类型用户的预约权限不同.当前用户为系统管理员时,具备为教工、学生、校外人员批量预约权限,此时校外人员的预约信息无需审核;当前用户为教工时,具备为自己或学生批量预约权限;当前用户为学生时,只能为自己预约;当前用户为外来人员时,只能为自己预约,且预约是否成功需要通过管理员审核,审核结果会采用websocket技术自动推送到用户的小程序端.
2 系统实现
系统的实现分前端和后端两部分.前端主要是小程序端,提供用户操作界面;后端对用户提交的信息进行处理,返回处理结果.本文以管理员批量预约流程为例阐述前端和后端的实现过程.
2.1 前端实现
前端使用微信小程序完成界面的绘制和数据的渲染,并将相关的请求发送给后端处理[3].用户身份核验界面截图见图4.
图4 身份核验界面截图
第一次使用时需要进行微信手机号授权登录,小程序会读取用户申请微信账号时所用的手机号,核验用户身份,核验无误后会返回token,同时会自动将token和非敏感用户信息缓存到服务器和微信小程序中.Token是用于和后端网络通讯的令牌,每次小程序对后端的网络请求都会携带token用于验证使用者的身份.由于本系统将部分信息缓存到小程序中,在缓存未失效前,用户可以直接进入预约界面.
实训室预约界面截图见图5,主要分3 部分.最上方为实训室选择区域,数据来自后端服务的渲染.用户切换不同的实训室,会根据系统时间同步刷新实训室的位置和当前时段剩余的工位数,选择不同的日期和时段也会同步刷新实训室的信息.中间部分为预约用户数据的录入、展示区域和预约按钮.系统在此处做了优化,可以输入学号、工号或者手机号中的任何一个信息,点击添加按钮后,会提交给后端服务逻辑进行甄别,以判断用户是否存在、用户是否重复预约等.若信息无误,用户信息会添加到预约名单中;若有问题,会以弹窗方式提示用户存在的问题.当用户点击预约按钮后,系统会将实训室编号、预约日期、预约时段、预约的用户信息和token信息等所有数据提交给后端,后端会将预约结果返回并渲染到界面的底部区域.
图5 预约界面截图
2.2 后端实现
后端使用Spring Boot 响应前端的请求,以JSON 格式返回处理结果.为了便于功能划分,后端设计的项目包结构见表7.
表7 项目包结构
当用户在小程序端提交预约数据时,会请求控制层对应的check方法,此方法仅用于接收用户请求数据和返回给小程序端的响应数据.为便于小程序处理响应的数据,返回数据格式封装为JSON 格式.具体的预约逻辑由服务层中handler Data完成.特别要注意的是,为防止不良用户的恶意接口调用,所有对后端服务的请求均需要接口鉴权[4].在本系统中,使用token完成鉴权.Token由后端服务分发给小程序端并保存在redis缓存服务中.小程序端每次请求业务接口时,都需要在请求头部带上token.后端服务接收到接口请求时,会验证token的合法性,如果不合法,会提示给客户端;如果合法,则进入业务处理流程.
Handler Data逻辑如下:(1)首先判断请求头中传入的token是否有效.Token信息存放在缓存服务器中,根据token信息换取当前用户的编号.(2)根据用户编号从用户信息表中查找用户的基本信息,关键是要获得用户的类型信息,用于检查是否拥有提交批量数据的权限.(3)将小程序端提交的实训室信息、时段信息和用户列表信息,按业务规范逐条写入到预约表并生成对应的二维码保存到磁盘中.每次写入数据前,都需要判断预约是否冲突或者重复预约.这是因为预约是并发的操作,预约名单上的人员和实训室信息在真正写入数据时,数据库中的信息可能已经发生了改变.这时需要开启数据表的表共享锁机制,以免造成脏数据的写入[5].(4)将预约结果信息返回给控制层check方法,在check方法中将预约结果封装,返回给小程序进行数据渲染.
3 系统存在的问题及建议
3.1 问题
(1)当为相同的用户预约同一时段时,不可避免地会产生预约冲突.若简单地在业务逻辑中进行处理的话,不但系统性能会降低,也容易引发数据库的死锁.
(2)预约信息过于依赖于用户的输入,校外人员还需要在计算机上人工审核,未能有效地利用先进的计算机技术.
(3)Token鉴权实现虽然简单,但如果接口请求量非常大,Token 可能会突然失效,会有大量的接口请求失败.
(4)目前,系统只能进行三个时段的预约:上午、下午及晚上,时段间隙过大,预约时间的精细度不够.
3.2 建议
(1)将用户信息和预约时段按一定的规范进行编码,存放到缓存服务中.业务处理时不直接操作数据库,在缓存服务中处理冲突,数据无误后再批量持久化到数据库中.
(2)在国家法律框架允许的情况下,引入OCR证件识别、人脸识别、NFC近场通讯等技术,进一步减少人为的操作,提高系统的便捷性.
(3)和其他系统对接时,采用接口签名方式验证接口的可用性.
(4)设计更合理的数据结构和编码算法,将时段选择改为时间选择,进一步提高系统的实用性.