高校實訓室預約系統(tǒng)的設計與實現(xiàn)

周科艷,周志堅

(無錫商業(yè)職業(yè)技術學院 經(jīng)濟管理學院,江蘇 無錫 214000)

目前,高校實訓室管理主要依靠管理員手工安排實訓室工位.隨著校企合作、舉辦技能競賽等需求的出現(xiàn),實訓室不僅需要對本校學生開放,也需要對校外人員開放[1].如果實訓室管理人員手工審核校外人員信息,會出現(xiàn)一些問題,如用戶身份核驗信息錄入時可能會出現(xiàn)數(shù)據(jù)錯誤;用戶無法及時反饋使用過程中的問題和建議;管理員只能調用自己所管轄的實訓室資源,無法利用其他的實訓室資源等.為此,本文以校園網(wǎng)為依托,采用前后端分離開發(fā)技術,設計了一套實訓室預約系統(tǒng),以期實現(xiàn)實訓室資源的優(yōu)化配置,提高實訓室的利用率.

1 實訓室預約系統(tǒng)設計

1.1 系統(tǒng)結構

系統(tǒng)的結構分為前端和后端兩部分.前端使用微信小程序實現(xiàn),運行在微信平臺上,為用戶提供預約、身份驗證等操作界面;后端主要采用SpringBoot框架處理用戶請求并響應結果[2].系統(tǒng)結構示意圖見圖1.

圖1 系統(tǒng)結構示意圖

后端除了使用Spring Boot框架構建業(yè)務系統(tǒng)外,還涉及到Docker容器、MySql數(shù)據(jù)庫、Redis緩存服務和FastJson等技術.Spring Boot框架用于快速構建業(yè)務后端服務系統(tǒng).MySql數(shù)據(jù)庫是一種關系型數(shù)據(jù)庫管理系統(tǒng),在本文設計的系統(tǒng)中用來存儲系統(tǒng)所需要的各項數(shù)據(jù).Redis是一個開源的內存數(shù)據(jù)結構存儲系統(tǒng),在本文設計的系統(tǒng)中使用它的緩存功能來驗證token信息,以提高系統(tǒng)的性能.前后端數(shù)據(jù)之間的通信采用JSON 格式,本系統(tǒng)使用FastJson對JSON 格式的數(shù)據(jù)進行解析和打包.當系統(tǒng)后端服務開發(fā)完畢后,將服務打包為jar文件,單獨部署到Docker 容器中.系統(tǒng)運行所需要的數(shù)據(jù)庫服務和緩存服務也可以通過Docker部署,以提高系統(tǒng)的性能和易用性.

1.2 數(shù)據(jù)庫設計

在整個系統(tǒng)中,涉及到的數(shù)據(jù)表有6個.第一個是實訓室信息表,見表1,主要記錄實訓室的名稱、地址、工位數(shù)目和其他相關信息.實訓室的名稱和地址可展示在預約用戶的操作界面上,實訓室的工位數(shù)目表示該實訓室可提供的工位.

表1 實訓室信息表

第二個是用戶信息表,見表2,主要記錄用戶姓名、用戶類型等相關信息.校內的學生和教工信息可以從學校的相關系統(tǒng)中導出,校外人員信息可以在預約過程中實時生成.username字段取值約定為:教工為工號,學生為學號,校外人員留空.major_id為教工和學生所屬專業(yè)的編號;對于校外人員,該編號設置為空.由于采用微信小程序驗證用戶信息,故還需要記錄用戶在小程序中的標識,即openid信息.為保證系統(tǒng)安全性,openid需要加密后保存.

表2 用戶信息表

第三個是專業(yè)信息表,見表3,主要記錄各實訓室涉及到的專業(yè).

表3 專業(yè)信息表

由于實訓室信息和專業(yè)信息是多對多的關系,因此需要第四個數(shù)據(jù)表來維護這種關系,見表4.

表4 專業(yè)-實訓室對應信息表

這些數(shù)據(jù)的維護由系統(tǒng)管理員完成,需要在使用系統(tǒng)前進行初始化.

第五個是預約記錄表,見表5,主要記錄用戶標識、實訓室標識、預約日期、預約時段、預約二維碼等.本系統(tǒng)支持當前用戶為其他用戶預約實訓室,user_id 字段記錄實際使用實訓室的用戶編號,prac_user_id字段記錄小程序用戶編號,若只為自己預約,兩個字段的值保持一致.status字段用于標志校外用戶的預約狀態(tài),status為1表示預約待審核,當系統(tǒng)管理員審核完成后,status置位0,同時生成二維碼.實訓室一旦預約成功,用戶可以在微信小程序中查看自己預約成功的二維碼,該二維碼用于掃碼入校和進入實訓室.

表5 實訓室預約記錄表

第六個是反饋記錄表,用于記錄用戶對實訓室的反饋情況,見表6,如用戶標識、實訓室標識、反饋日期、反饋內容等.

表6 實訓室反饋記錄表

1.3 功能設計

本系統(tǒng)主要實現(xiàn)如下功能:實訓室使用者可以使用微信小程序進行實訓室預約、查看預約結果和反饋實訓室存在的問題;實訓室管理員可以通過后端實時了解實訓室的工位安排情況,并通過身份驗證機制合理分配實訓室工位.

實現(xiàn)上述功能需要兩個模塊.一是用戶身份核驗模塊,流程見圖2.對于校內人員,由于系統(tǒng)管理員在后臺已將數(shù)據(jù)導入到用戶信息表中,直接使用微信注冊的手機號授權登錄即可;若手機授權無法登錄,說明手機號不在用戶信息表中,表示該用戶為第一次使用本系統(tǒng)的校外人員,界面將轉入個人信息維護界面.二是預約模塊,預約流程見圖3.用戶在預約界面提交實訓室信息和預約信息后,即可完成預約.

圖2 身份核驗流程

圖3 預約流程

在預約模塊中,最核心的內容是預約邏輯的實現(xiàn).使用本系統(tǒng),既可以本人預約,也可以替用戶信息表中的其他用戶預約,還可以進行批量用戶預約,這樣就可以大大方便管理人員操作.

為保證系統(tǒng)的安全性,不同類型用戶的預約權限不同.當前用戶為系統(tǒng)管理員時,具備為教工、學生、校外人員批量預約權限,此時校外人員的預約信息無需審核;當前用戶為教工時,具備為自己或學生批量預約權限;當前用戶為學生時,只能為自己預約;當前用戶為外來人員時,只能為自己預約,且預約是否成功需要通過管理員審核,審核結果會采用websocket技術自動推送到用戶的小程序端.

2 系統(tǒng)實現(xiàn)

系統(tǒng)的實現(xiàn)分前端和后端兩部分.前端主要是小程序端,提供用戶操作界面;后端對用戶提交的信息進行處理,返回處理結果.本文以管理員批量預約流程為例闡述前端和后端的實現(xiàn)過程.

2.1 前端實現(xiàn)

前端使用微信小程序完成界面的繪制和數(shù)據(jù)的渲染,并將相關的請求發(fā)送給后端處理[3].用戶身份核驗界面截圖見圖4.

圖4 身份核驗界面截圖

第一次使用時需要進行微信手機號授權登錄,小程序會讀取用戶申請微信賬號時所用的手機號,核驗用戶身份,核驗無誤后會返回token,同時會自動將token和非敏感用戶信息緩存到服務器和微信小程序中.Token是用于和后端網(wǎng)絡通訊的令牌,每次小程序對后端的網(wǎng)絡請求都會攜帶token用于驗證使用者的身份.由于本系統(tǒng)將部分信息緩存到小程序中,在緩存未失效前,用戶可以直接進入預約界面.

實訓室預約界面截圖見圖5,主要分3 部分.最上方為實訓室選擇區(qū)域,數(shù)據(jù)來自后端服務的渲染.用戶切換不同的實訓室,會根據(jù)系統(tǒng)時間同步刷新實訓室的位置和當前時段剩余的工位數(shù),選擇不同的日期和時段也會同步刷新實訓室的信息.中間部分為預約用戶數(shù)據(jù)的錄入、展示區(qū)域和預約按鈕.系統(tǒng)在此處做了優(yōu)化,可以輸入學號、工號或者手機號中的任何一個信息,點擊添加按鈕后,會提交給后端服務邏輯進行甄別,以判斷用戶是否存在、用戶是否重復預約等.若信息無誤,用戶信息會添加到預約名單中;若有問題,會以彈窗方式提示用戶存在的問題.當用戶點擊預約按鈕后,系統(tǒng)會將實訓室編號、預約日期、預約時段、預約的用戶信息和token信息等所有數(shù)據(jù)提交給后端,后端會將預約結果返回并渲染到界面的底部區(qū)域.

圖5 預約界面截圖

2.2 后端實現(xiàn)

后端使用Spring Boot 響應前端的請求,以JSON 格式返回處理結果.為了便于功能劃分,后端設計的項目包結構見表7.

表7 項目包結構

當用戶在小程序端提交預約數(shù)據(jù)時,會請求控制層對應的check方法,此方法僅用于接收用戶請求數(shù)據(jù)和返回給小程序端的響應數(shù)據(jù).為便于小程序處理響應的數(shù)據(jù),返回數(shù)據(jù)格式封裝為JSON 格式.具體的預約邏輯由服務層中handler Data完成.特別要注意的是,為防止不良用戶的惡意接口調用,所有對后端服務的請求均需要接口鑒權[4].在本系統(tǒng)中,使用token完成鑒權.Token由后端服務分發(fā)給小程序端并保存在redis緩存服務中.小程序端每次請求業(yè)務接口時,都需要在請求頭部帶上token.后端服務接收到接口請求時,會驗證token的合法性,如果不合法,會提示給客戶端;如果合法,則進入業(yè)務處理流程.

Handler Data邏輯如下:(1)首先判斷請求頭中傳入的token是否有效.Token信息存放在緩存服務器中,根據(jù)token信息換取當前用戶的編號.(2)根據(jù)用戶編號從用戶信息表中查找用戶的基本信息,關鍵是要獲得用戶的類型信息,用于檢查是否擁有提交批量數(shù)據(jù)的權限.(3)將小程序端提交的實訓室信息、時段信息和用戶列表信息,按業(yè)務規(guī)范逐條寫入到預約表并生成對應的二維碼保存到磁盤中.每次寫入數(shù)據(jù)前,都需要判斷預約是否沖突或者重復預約.這是因為預約是并發(fā)的操作,預約名單上的人員和實訓室信息在真正寫入數(shù)據(jù)時,數(shù)據(jù)庫中的信息可能已經(jīng)發(fā)生了改變.這時需要開啟數(shù)據(jù)表的表共享鎖機制,以免造成臟數(shù)據(jù)的寫入[5].(4)將預約結果信息返回給控制層check方法,在check方法中將預約結果封裝,返回給小程序進行數(shù)據(jù)渲染.

3 系統(tǒng)存在的問題及建議

3.1 問題

(1)當為相同的用戶預約同一時段時,不可避免地會產(chǎn)生預約沖突.若簡單地在業(yè)務邏輯中進行處理的話,不但系統(tǒng)性能會降低,也容易引發(fā)數(shù)據(jù)庫的死鎖.

(2)預約信息過于依賴于用戶的輸入,校外人員還需要在計算機上人工審核,未能有效地利用先進的計算機技術.

(3)Token鑒權實現(xiàn)雖然簡單,但如果接口請求量非常大,Token 可能會突然失效,會有大量的接口請求失敗.

(4)目前,系統(tǒng)只能進行三個時段的預約:上午、下午及晚上,時段間隙過大,預約時間的精細度不夠.

3.2 建議

(1)將用戶信息和預約時段按一定的規(guī)范進行編碼,存放到緩存服務中.業(yè)務處理時不直接操作數(shù)據(jù)庫,在緩存服務中處理沖突,數(shù)據(jù)無誤后再批量持久化到數(shù)據(jù)庫中.

(2)在國家法律框架允許的情況下,引入OCR證件識別、人臉識別、NFC近場通訊等技術,進一步減少人為的操作,提高系統(tǒng)的便捷性.

(3)和其他系統(tǒng)對接時,采用接口簽名方式驗證接口的可用性.

(4)設計更合理的數(shù)據(jù)結構和編碼算法,將時段選擇改為時間選擇,進一步提高系統(tǒng)的實用性.