體育館場地管理系統1.0-2.0

文章目錄

• • 前言
  • • 1.0版本
    • • 1.項目功能簡述
      • 2.項目目錄結構
      • 3.資料庫設計
      • 4.前端邏輯設計
      • 5.後端邏輯設計
    • 2.0版本
    • • 1.上個版本的問題
      • 2.項目目錄結構--使用者部分
      • 3.改造後
      • 4.改造思路
      • 5.其他說明
    • 項目位址

前言

去年大二的時候，學校讓我們自己做工程實踐項目，我和隊友選擇了做體育館場地管理系統。那個時候我們在網上找相關的技術部落格、開源項目等就發現很少，今年五月份，我們又重構了之前的系統。是以，我準備寫一篇文章介紹一下我們的體育館場地管理系統。

1.0版本

1.項目功能簡述

• 該項目分為和使用者互動的部分（前台）和管理者部分（背景）兩個部分
• 前台功能：登入注冊部分、首頁部分、個人中心部分

  

• 背景功能：登入部分、功能查詢部分

  

  

2.項目目錄結構

• 1.0版本使用原生Javaee+Jsp+Mysql，采用mvc分層方式搭建。
• 資料庫連接配接工具使用的是c3p0,資料庫操作用的Commons，同時用到了封裝的一些sql封裝操作。
• 用原生監聽器完成定時任務。
• 原生過濾器實作安全跳轉，因為有些位址是在沒有登入的情況下不能通路的，這裡隻是用了兩層目錄的方式來控制。
• mvc三層中，admin和user分别對應着管理者和前台的代碼實作。
• baseServlet是使用了反射，來簡化原生的servlet。

3.資料庫設計

表結構：

1. gms_admin(管理者表)：隻有一條資訊，為管理者的
2. gms_notice(通知表)：通知資訊，預設寫了七條資料，太少前端展示有問題
3. gms_order(訂單表)：使用者下單後訂單記錄
4. gms_type(場館類型表)：比如籃球場就位類型，籃球場1号…就為具體場地
5. gms_user(使用者表)：存放使用者注冊資訊
6. gms_venue(場館表)：具體某個場館，比如乒乓球1号，2号，3号…
7. gms_vdstate(場館分時狀态表)：一個場館gms_venue對應多個分時狀态，因為我們要展示最近三天内容，一天中以一小時間隔會有23個時間段，設計23個字元來表示狀态以0,1,2分别表示三種顔色，場館三種顔色(綠色、灰色、白色)表示狀态，根據0,1,2就可以展示場館狀态。

   

01表示對應的場館編号，第二個字段表示哪一天，0表示不可預約(灰色)，1表示可預約(白色)，2表示已預約(黃色)，後面23個字元，比如這裡第一個2在第十三個字元位置，是以12:00-13:00位已預約

4.前端邏輯設計

以上部分的解釋如下：

1. 紅點1這裡使用的是Bootstrap的标簽頁，我們點選需要的場館(紅點2)，下面就會展示對應的場館資訊（紅點3）
2. 場館類型(紅點2)，通知消息(紅點4)，頁面加載的時候就用ajax加載了所有的場館類型并且展示，今日日期(紅點5)也是頁面加載的時候就進來了
3. 紅點6是通過紅點2和紅點5即場館類型和目前日期去查詢資料庫查出來的
4. 具體邏輯:首先在頁面加載的時候，場館類型，詳細資訊，通知資訊，目前日期，這些可以直接在ajax中擷取并展示出來，然後在場館類型的每個類型裡面設定一個方法，點選這個方法的時候就會擷取目前的日期，這樣就可以直接請求擷取所有場館資訊了。注意： 但是每次點選的時候必須先清除上一次展示的場館資訊，否則就會重疊。還有個問題，當我們點選了這個場館選擇後，變為綠色了，又去另外一個界面點選一下，傳回過來綠色消失了，是以必須記錄下這個顔色然後在展示清單資訊。

5.後端邏輯設計

1. 選擇場館的時候，我們需要生成一張訂單表，同時修改資料庫分時狀态表的狀态，告訴前台這個場館被人預約了，同時要插入一條訂單表到資料庫，這兩個操作是保持一緻性的，是以要加事務控制。
2. 訂單在個人中心是可以提前取消預約的，那我們還是要修改分時狀态表，以及修改訂單表的狀态為已取消，也要加事務控制。
3. 定時任務是指：前端展示的時候顯示了這一天的場館這狀态，比如目前時間是12:00，那麼12:00之前的場館狀态就必須被修改為不可預約，避免使用者再預約之前的場館導緻問題。同時，訂單表也要修改，因為如果有些人預約的是12:00-13:00的場館，目前時間已經為13:01的時候，這個訂單要麼被使用者使用了，要麼逾時了，我們都需要将這個訂單設定為已完成訂單狀态，每隔一分鐘修改一次。
4. 簡單的登入、注冊、修改密碼、登出登入這裡就不提了，還有個導出訂單表的操作，是自己寫的工具類，會調用就行了。

2.0版本

1.上個版本的問題

1. 沒有考慮線程安全問題—>多個使用者同時預約同一個場館。
2. 分時狀态表的設計問題，以23個字元來控制每個時間段的狀态會導緻很多問題。
3. 通路權限問題以及安全跳轉問題。

2.項目目錄結構–使用者部分

1. 項目還是兩部分，管理者和使用者，由于是兩個人開發的，是以用了兩個端口号，隻是操作的同一個資料庫。
2. 2.0在1.0的基礎上使用SpringBoot+Vue搭建，其中Vue隻是用來當模闆引擎，用jquery操作。
3. 項目使用maven建構，使用git作為項目版本管理。
4. 資料庫連接配接使用druid，資料庫操作使用MyBatis架構。
5. 使用thymeleaf作為url跳轉使用，前後端使用json傳輸資料，實作前後端分離。
6. 使用郵件發送通知，同時使用消息隊列rabbitMq異步發送郵件。
7. 使用Spring Security作為權限管理，控制位址通路安全問題。
8. 使用加鎖的方式解決線程安全問題，并用jmeter壓力測試。
9. 管理者改動不大，springboot+vue+定時任務+spring security
10. 後續可繼續改進：将分時狀态表改為每個時間段一個，增加redis緩存以讓首頁減小壓力。

3.改造後

登入注冊：

首頁部分：

1. 之前是通過一個中間界面來展示預約的資訊，但是在前後端分離中很難設計，需要跳轉，是以我在首頁點選的下面展示點中的場館，這樣的話也為以後點選多個場館預約留下了接口。

2. 這裡其實用了加鎖的操作，具體思路在項目的改造思路_User.md裡面

   個人中心部分：

   

為什麼要用rabbitMq來發送異步郵件：

1. 當我們選擇好場館送出後就要執行發送郵件任務，由于發送郵件很慢，是以放到消息隊列裡會好很多
2. 也可以自己手動建立一個線程來專門發送郵件，這裡隻是為了鍛煉一下自己的消息隊列使用情況
3. 如果不想發送郵件可以在代碼中注釋點，代碼裡的注釋很詳細

4.改造思路

管理者和使用者部分的改造思路都在我的項目裡面，大家可以通過在我的github上面看到，這裡就不詳述了。

5.其他說明

1. 項目的搭建過程以及需要注意的事項我都放在github上面了。
2. 本文我并未介紹管理者部分的功能和代碼設計，其中還是有很多比一般管理者部分設計的好的地方。
3. 文中提到的内容均為大的點，很多小的細節，在1.0中可能并沒有全部記錄，但是2.0中都記錄到了改造思路裡面。
4. 轉載請附加原文連結

項目位址

如果你對源碼感興趣的話，以下是我的項目的兩個連結，其中包含了詳細的搭建過程，如果覺得可以的話，麻煩點個star，謝謝。

1.0版本github連結

2.0版本github連結