基于微信小程序+SSMSD框架的目標考核管理系統

李潤龍　楊延喆　葛萌

關鍵詞：微信小程序；目標考核管理系統；MVVM模式；SSMSD框架

中圖分類號：TP311 文獻標識碼：A 文章編號：1006-8228（2023）11-167-05

0 引言

目標考核是高等院校每年必做的一項重要工作，目標考核從多個指標來考核各二級學院或者教職工年度任務完成情況。據了解，目前各高校在實施目標考核工作時，存在著如下問題：①部分院校還停留在手工統計階段，僅有部分指標有其對應的管理系統（如科研部分有對應的科研管理系統），沒有一個整體圍繞目標考核工作的信息系統，“信息孤島”問題嚴重制約了目標考核工作；②已有目標考核系統的院校，教師用戶在數據錄入時只能通過PC 端進行操作，而缺少移動端相關應用程序的支撐。

依據上述背景，本文設計并實現了一款高等院校目標考核管理系統。其客戶端包括PC 和微信小程序兩部分，服務器端采用輕量級Java EE 平臺-SSMSD框架進行設計并實現，PC 客戶端采用HTML5+Vue.js進行設計并實現。微信小程序為教師用戶錄入考核數據提供了便利。

1 相關技術

1.1 微信小程序及開發(fā)方案

微信小程序是微信功能擴展的重要接口，相對于傳統的手機APP，利用微信小程序開發(fā)的應用程序具有安裝簡單、成本低、平臺兼容性好、節(jié)省手機內存等特點[1-2]。依賴于龐大的微信用戶市場，微信小程序便于推廣和普及。小程序云開發(fā)[3]是微信團隊與騰訊云攜手開發(fā)的一套小程序的解決方案。該方案提供了簡單易上手的API，可以滿足基本的業(yè)務開發(fā)需求，無需購買服務器、數據庫等后端資源[4]。與傳統開發(fā)模式相比，具有節(jié)約成本、開發(fā)效率高、穩(wěn)定性好等優(yōu)點。

1.2 SSMSD 框架

SSMSD 框架是Spring MVC+Spring+MyBatis+Spring Data 的簡稱，它是目前主流的Java EE 服務器端的輕量級開發(fā)框架，具有運行速度快、開發(fā)效率高等特點。Spring 框架包含兩大核心技術[5]，分別是：IOC（Inverse of Controll， IOC）和AOP（Aspect OrientedProgramming， AOP）。IOC 用于JavaBean 對象的管理，包括Bean 的實例化、屬性設置、使用和銷毀。AOP 通過動態(tài)代理技術以切面形式實現動態(tài)方法增強，用于權限驗證、日志記錄、性能監(jiān)控、事務管理等場景。

Spring 能夠完成對Controller 和SqlSessionFactory 對象的依賴注入，實現對Spring MVC 和MyBatis 框架的整合。

Spring MVC 是一款請求驅動類型的框架，是Spring 的Web 組成部分。Spring MVC 基于MVC 模式，通過核心控制器、處理器映射器、處理器適配器、處理器和視圖解析器等組件將Web 應用劃分為視圖、模型和控制器等部分，并確保它們之間的松耦合關系[6]。

MyBatis 框架對JDBC 進行了輕量級封裝，解決了原生JDBC 進行數據持久化操作時所產生的冗余度高、Java 代碼與SQL 語句耦合度高等缺點[7]。通過XML 文件或注解方式結合DAO 接口，實現SQL 語句和Java 對象之間的映射。

Spring Data 是Spring 中用來進行數據源訪問的子框架。Spring Data 提供了統一的方式進行關系型數據庫和非關系型數據庫的操作，包括基本的添加、刪除、修改、查詢、排序和分頁等。

1.3 MVVM 模式

MVVM（Model-View-ViewModel） 是在MVC 模式基礎上發(fā)展起來的一種前后端分離的設計模式[8]。其中Model 代表的是數據模型，存儲后端業(yè)務邏輯處理的結果。View 代表的是UI 組件，主要負責將模型數據展示給用戶。ViewModel 是一個同步View 和Model 的組件，它負責將Model 和View 解耦合，它能夠保證Model 中數據的發(fā)生及時在View 中展示出來；相反，View 中數據變化時也能同步到Model 中保存。

2 系統分析

2.1 目標考核工作流程

目標考核通過設立指標體系來考查二級學院的年度任務完成情況。指標體系包括綜合指標和業(yè)績指標兩大類。綜合指標設立三級指標體系，其中一級指標包括：教育教學、科研與學科建設、師資隊伍、學生工作和黨建工作。每個一級指標具有不同的占比。每個一級指標包含若干二級指標，每個二級指標包含若干三級指標。每個三級指標具有具體的得分計算規(guī)則。

年初由各職能部門按照所分管的指標為各二級學院下達年度工作任務量，經過發(fā)展規(guī)劃處將任務量審核后正式下達二級學院進行實施。每位教職工按照指標錄入相對應的支撐數據，由二級學院管理員以及對應職能部門管理員審核后，生成對應三級指標的得分數據。三級指標得分累加得到二級指標得分，二級指標累加得到一級指標得分，各一級指標按權重累計得到綜合指標得分，綜合指標加上業(yè)務指標得分即為某個二級學院年度考核最終得分。

2.2 角色劃分

經過需求分析，系統中包含的角色有：教師、二級學院管理員、教務處管理員、科研處管理員、發(fā)展規(guī)劃處管理員、人事處管理員、黨委宣傳部管理員、黨委統戰(zhàn)部管理員、招就處管理員、團委管理員、學科辦管理員、學生處管理員、招生就業(yè)處、校領導和系統管理員等多個角色。上述所有角色對應的功能在PC 端都能完成，微信客戶端只提供教師角色功能。教師角色為系統中最重要的一個角色，主要承擔著錄入各項考核指標數據的任務，包括教學數據、科研數據、突出業(yè)績等三大部分。

2.3 系統功能模塊

主要模塊包括：指標管理、教學數據管理、科研數據管理、突出業(yè)績管理、師資隊伍數據管理、學生工作數據管理、黨建數據管理、目標任務管理、報表管理、信息查詢和系統維護。部分主要模塊功能如下：

教學數據管理模塊需要教師錄入教學任務、課程設計、出版的教材、獲批的教改項目、調課記錄、教師本人參加教學競賽、指導學生的大創(chuàng)項目等信息。教學數據的審核部分歸二級學院管理員審核、部分歸教務處審核。

科研數據管理模塊需要教師錄入所發(fā)表的論文、申請的專利、獲批的項目（縱向和橫向）、出版的專著以及科研獲獎等數據。這部分數據由科研處管理員負責審核。

突出業(yè)績管理部分需要教師錄入指導學生獲獎的各類學科競賽、教師個人獲得的榮譽稱號（例如學科帶頭人、學術帶頭人、各類先進等）、以及參與的各類科研團體（平臺）等信息。指導學生獲獎各類競賽由教務處負責審核，教師個人榮譽由人事處負責審核，參加各類科研團體由科研處負責審核。

系統維護是對各個學院以及教師在教學、科研和突出業(yè)績等活動過程產生數據的查看和統計，如日志記錄與統計報表。日志記錄是實時記錄用戶的相關活動；統計報表側重于整體狀況，以統計圖的形式反映不同年份、同一指標的信息，并將信息進行直觀的對比，為后續(xù)制定目標任務等提供決策依據。

3 系統設計與實現

3.1 系統架構

系統總體采用Java EE 分層架構[9]+前后端分離技術進行設計與實現，具體如圖1 所示。前端包括Web瀏覽器和微信小程序兩個平臺，主要完成表示層的功能，包括頁面數據渲染、展示和用戶交互。后端共享一個Java EE 服務器端平臺，包括控制層、業(yè)務邏輯層和數據持久層和數據庫，數據庫采用關系型數據庫MySQL 和非關系型數據庫MongoDB。每一層的具體功能如下：

⑴ 表示層：該層分為前端UI 和交互。前端UI 負責系統程序的頁面展示、數據渲染等功能，交互層負責一些簡單的數據校驗和前端的邏輯交互，并與控制層的Shiro 權限校驗進行關聯，對用戶進入系統后的行為進行校驗與授權。

⑵ 控制層：該層使用Spring MVC 框架負責具體業(yè)務流程的控制，完成客戶端的請求轉發(fā)以及響應。使用Apache 的Shiro 框架對系統角色的權限進行劃分。Shiro 中的Subject 可以理解為用戶的形參，用戶通過Subject 與系統進行交互，用來實現登錄、退出、權限校驗等操作。SecurityManager 是整個Shiro 框架的核心，它管理著所有Subject。Realms 用于用戶認證授權，可以通過繼承AuthorizingRealm 類來實現自定義的Realm 方法。

⑶ 業(yè)務邏輯層：該層用來連接控制層和數據持久層，首先接收控制層傳入的參數通過定義Service 對象完成業(yè)務操作，然后定義持久層需要的PO 對象，調用持久層DAO 對象完成持久化操作。上述過程需要的Controller、Service 以及DAO 對象都納入SpringIOC 容器進行管理。

⑷ 數據持久層：數據持久層主要用來與數據源進行交互，為應用系統提供獲取和保存數據的功能。本層一共使用三種不同的數據持久化技術，其中MyBatis和Spring Data JDBC 用來操作MySQL 數據庫；Spring Data MongoDB 負責操作MongoDB 數據庫。

⑸ 數據庫：數據庫使用了MySQL 和MongoDB兩種數據庫。其中MySQL 定義了教師信息表、指標體系表、考核信息表、論文表、專著表、科研項目表等。在MongoDB 中的集合包括論文、獲獎、著作、項目等所有考核信息對應的支撐材料集合。系統將考核數據保存在MySQL 的同時，會獲取支撐材料所對應的集合名稱和對象id，并將其保存到對應的MySQL 數據表的字段中。

3.2 系統實現的關鍵技術

3.2.1 微信端保持登錄狀態(tài)

由于微信端通過wx.request（）方法發(fā)起的每次請求對于服務端來說都是不同的會話，微信端需要在與服務器端的多次通信中保持同一個會話狀態(tài)，因此需要微信端每次向服務器端發(fā)送請求時保持同一個Sessionid。具體的解決辦法是：先從微信端登錄，通過后，在服務器端通過request 對象的getSession（）方法獲得Sessionid，然后通過response 對象寫回到微信端。微信端將接收到的Sessionid 保存到全局變量globalData 的header 中。由于微信端支持請求頭操作，以后向服務器端發(fā)送請求時就可以通過請求頭將之前保存的Sessionid 發(fā)回給服務器端，從而保持登錄狀態(tài)。上述操作的具體交互過程如圖2 所示。

3.2.2 使用策略設計模式計算指標得分

目標考核中的一個核心任務就是計算每個二級學院的年度任務得分。由于每一個三級指標的考核計算邏輯各不相同，而且同一個三級指標在不同考核年份的計算邏輯也可能不同。為了確保指標得分計算邏輯和其他的業(yè)務邏輯解耦合，使用策略設計模式對指標得分計算邏輯進行了封裝。以“國家級項目申報”這個三級指標為例，對應的策略設計模式類圖[10]關系如圖3 所示。其中ScoreStrategy 為策略接口，其中定義兩個指標得分計算方法，其中comScore 表示某個二級學院在指定年份的綜合指標得分；perScore表示某個二級學院在指定年份的業(yè)績指標得分。NationalProjectScoreStrategyOne、NationalProjectScore-StrategyTwo 為不同的具體策略接口實現類，按照某種計算邏輯完成綜合指標得分和業(yè)績指標得分，National-ProjectScoreStrategyOne 中對于綜合指標得分的計算邏輯是：comScore=（relNum/taskNum）*15，relNum 為引用ProjectDAO 對象獲取某個二級學院在指定年份獲批的國家級項目數量；taskNum 為引用SRTaskDAO 對象獲取某個二級學院在指定年份的國家級項目任務量。ScoreStrategyContext 為策略接口應用的上下文，通過關聯策略接口實現對某個具體策略類的注入以及完成對策略方法的調用；ProjectServiceImpl 為科研項目實體對應的Service 實現類，其中，通過關聯策略上下文實現對具體策略的調用，策略上下文實現了對具體策略類和Service 實現類的解耦合。如果指標得分的計算邏輯發(fā)生變化，只需重新定義或者更換策略實現類并且在上下文進行引用的更換即可，從而保證Service 實現類中業(yè)務邏輯的不變性。

3.2.3 混合持久化技術的數據持久層設計

借鑒領域驅動設計中有關戰(zhàn)略設計的聚合思想進行數據持久層設計，綜合使用了Spring DataJDBC、MyBatis 和Spring Data MongoDB 3 種持久化技術。目的是為了充分利用不同數據持久化的特性，簡化代碼編寫量，提高開發(fā)效率和可擴展性。在實體類中，以教師信息為考核信息的聚合根，對于教師實體的單表數據庫操作，可以使用Spring Data JDBC 進行，因為它能夠簡化單表操作中實體類與結果集的映射關系?？己诵畔⑹歉綄儆诮處煂ο蟮膶傩?，其操作通常涉及多表查詢、動態(tài)SQL 等復雜操作，通過在MyBatis 的映射文件中定義SQL 語句來執(zhí)行。當保存考核數據時，需要將信息對應的支撐材料保存到MongoDB，并將該文件生成的UUID 分別保存到MySQL 和MongoDB 數據庫中，可以使用SpringData MongoDB 所提供的文件保存方法和MyBatis 所提供的數據更新方法。

上述操作可以定義在一個DAO 接口中（TargetInfoDAO），如圖4 所示。繼承CrudRepository 接口可以使用Spring Data JDBC 提供的持久化方法，Mapper 接口中定義使用MyBatis 框架的持久化方法，MongoDBRepository接口中定義使用Spring Data MongoDB的持久化方法。定義ExtensionMapper 接口和ExtensionMongoDB接口是為了Spring Data JDBC 中整合MyBatis 和Spring Data MongoDB，在這兩個接口的實現類中完成對Mapper 接口和MongoDBRepository接口中持久化方法的引用。這樣設計之后，在Service層就可以通過一個DAO 接口完成對實體類的所有持久化操作的調用，簡化了Service 層注入持久層接口的數量，使得業(yè)務層代碼更加簡潔明了。

4 系統測試

首先采用黑盒測試針對各角色用戶進行功能用例測試，確保各用例邏輯正確。然后采用JMeter 對服務器端進行性能測試，服務器內存16G，CPU 為IntelCore i7。以微信端教師角色常用的登錄和科研信息查詢操作為例，參考學校教工人數設置用戶線程組為1000 并同時啟動，選擇監(jiān)聽器Aggregate Graph，測試數據如表1 所示。

根據測試數據表明：在1000 并發(fā)量的情況下，服務器平均響應時間在1s 以內，99% 的請求都在2s 內完成，各操作的平均吞吐量為110。說明采用本文方法所創(chuàng)建的系統性能良好，能夠滿足當前實際需要。

5 結束語

針對目標考核工作中存在的問題，利用微信小程序和SSMSD 框架，設計并實現了一個目標考核系統。從系統功能模塊、系統架構和關鍵技術等方面詳細描述了系統實現過程，通過系統的使用提高了考核工作的信息化和管理水平，為教師用戶的數據錄入提供了便利。下一步將圍繞職能部門用戶進行微信客戶端功能的擴充，并對指標領域進行優(yōu)化，確?？己酥笜伺c業(yè)務過程更加解耦，從而提高系統的適應性和擴展性。