簡介基于SSMSpringSpringMVCMyBatis與MySQL實現(xiàn)的酒店客房預定管理系統(tǒng)是一套面向計算機專業(yè)畢業(yè)設計、課程設計及SSM框架進階學習者的完整項目資源。系統(tǒng)覆蓋個人中心、用戶管理、客房類型管理、酒店客房管理、客房預定管理、開房記錄管理、退房結賬管理、系統(tǒng)管理等核心業(yè)務并設有管理員與普通用戶兩級權限同時支持入住率報表、客房類型統(tǒng)計等數(shù)據(jù)分析功能能完整體現(xiàn)SSM框架在Web業(yè)務系統(tǒng)中的應用思路。壓縮包共1254個文件大小約18.9MB其中包含112個Java源文件、103個JSP頁面、364個JavaScript腳本、146個CSS樣式文件以及大量圖片素材、SQL數(shù)據(jù)庫腳本、設計文檔、部署說明和視頻演示。源碼分層清晰Controller、Service、Mapper結構一目了然SQL腳本提供建表語句和初始數(shù)據(jù)部署說明可幫助快速搭建運行環(huán)境。目前已有185人學習下載項目源碼經(jīng)過測試校正可百分百運行適合需要直接獲得可運行工程以支撐畢業(yè)設計、課程答辯或項目實戰(zhàn)的讀者也可用于二次開發(fā)和功能擴展實踐價值較高。1. 拿到“基于SSMMySQL的酒店客房預定管理系統(tǒng)”壓縮包之后第一件事不是解壓A同學把壓縮包解壓后把里面每個看起來像啟動入口的文件都雙擊了一遍一個都沒起來。這不是手氣問題——這個標題拆開就是一套典型的Java Web后臺SpringSpringMVCMyBatis做三層架構MySQL存數(shù)據(jù)業(yè)務范圍是客房查詢、預訂、入住、退房。系統(tǒng)把原來寫在臺賬上的房間狀態(tài)和訂單狀態(tài)變成了數(shù)據(jù)庫表和一條條SQL。它適合正在做課程設計、剛接觸SSM、或者需要拿一個可運行項目當腳手架的人。為什么說第一件事不是解壓因為不知道啟動方式就雙擊結果多半是被環(huán)境問題勸退。2. SSM MySQL為什么能撐起酒店客房預訂三層架構與業(yè)務狀態(tài)流轉在我經(jīng)手過的教學項目里SSM這套組合被吐槽最多的就是“老”。但放到這個標題的語境里它反而是優(yōu)點Spring管對象和依賴SpringMVC管請求分發(fā)MyBatis管SQL映射三層邊界清楚出了問題能直接定位到某一層。這一章先把架構和業(yè)務講透后面部署、排錯才有根據(jù)。2.1 為什么還在用SSM三層架構解決的是代碼堆一起的問題SSM三個成員各自只干一件事。Spring管理所有對象的創(chuàng)建和依賴關系Service層要用的Mapper接口由它注入不需要你手動newSpringMVC接收瀏覽器來的HTTP請求按URL把請求分給對應ControllerController再把視圖名返回給前端頁面MyBatis負責把Mapper接口的方法和XML里的SQL綁起來。數(shù)據(jù)流向是固定的瀏覽器發(fā)起請求→DispatcherServlet→Controller→Service→Mapper接口→MySQL查詢結果再按原路返回。這套流程里有個容易被忽略的好處Controller不寫SQLMapper不寫業(yè)務。新接手的人拿到工程看Controller只知道入口看Service知道業(yè)務規(guī)則看Mapper XML才知道具體查了哪張表三層各查各的定位問題很快。相比之下Spring Boot也基于這三大件只是把配置自動裝配了。如果這是一個需要寫設計文檔、需要講清“為什么這樣分層”的交付物手寫SSM配置反而更容易展開講。我一般會建議拿到這類工程后先畫一張“請求→響應”的鏈路圖標出每個請求進了哪個Controller再調了哪個Service最后用到哪張表。這張圖畫得出來系統(tǒng)就懂了六成。畫不出來的部分就是設計文檔或者代碼里寫得比較含糊的部分答辯前要重點補。2.2 業(yè)務閉環(huán)查房、下單、入住、退房兩套狀態(tài)不能混酒店預訂的核心流程不復雜但容易在狀態(tài)設計上翻車。完整閉環(huán)是用戶按入住日期和離店日期查房選一間可售房間生成預訂訂單支付后訂單變成已支付待入住客人到店前臺辦入住房間從“已訂”變成“已入住”退房時做結算房間變成“清潔中”打掃完再變回“空閑可售”。最關鍵的是一件事房間狀態(tài)和訂單狀態(tài)是兩套獨立狀態(tài)不能混著設計。一個房間可以沒有訂單但處于清潔中一個訂單可以已支付但房間還沒下來。我建議按下面的取值設計房間狀態(tài)含義訂單狀態(tài)含義0空閑可售0待支付1已預訂未入住1已支付/待入住2已入住2已入住3清潔中/維修3已退房/已完成——4已取消設計文檔如果寫得細還會對每個狀態(tài)遷移標注“操作人觸發(fā)動作”比如訂單從0到1操作人是用戶動作是支付房間從2到3操作人是前臺動作是退房。檢查這個表就能看出流程有沒有漏洞——哪個狀態(tài)沒有操作入口或者哪個操作不改變任何狀態(tài)那就是設計多了一步或少了一步。2.3 角色與權限三個入口一個登錄會話這類系統(tǒng)一般分三類角色普通用戶在網(wǎng)站端查房、下單、取消訂單前臺辦理入住和退房管理員維護房型價格、查看所有訂單。權限上不需要引入復雜的RBAC表常見的做法是登錄后在Session里存用戶對象和用戶類型用SpringMVC攔截器做訪問控制。mvc:interceptors !-- 攔截所有請求未登錄跳轉到登錄頁 -- mvc:interceptor mvc:mapping path/**/ mvc:exclude-mapping path/login/**/ mvc:exclude-mapping path/static/**/ bean classcom.hotel.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptors這里有兩個必須注意的點一是exclude-mapping必須放行靜態(tài)資源和登錄接口否則CSS進不來、登錄請求也被攔二是攔截器里判斷用戶類型時要對管理端路徑做前綴匹配不能讓普通用戶直接訪問/admin/**。攔截器只攔截“有沒有登錄”角色判斷放在Controller方法里或攔截器里二次判斷粒度為“菜單級別”就夠了。3. 客房預訂系統(tǒng)的數(shù)據(jù)庫設計拆表、狀態(tài)機與DDL要點數(shù)據(jù)庫是整個系統(tǒng)里最先能看出水平的部分。這個標題的業(yè)務不算復雜但表拆得好不好直接決定后面改需求時是改一行配置還是改一坨SQL。我的建議是按住以下幾張表就夠了用戶表、房型表、房間表、訂單表復雜的可以再加一張操作日志表。下面按最核心的三張表展開。3.1 把“房型”和“房間”分開建模價格、面積、床型、可住人數(shù)這些屬性屬于“房型”這一級房間號、樓層、當前狀態(tài)屬于“房間”這一級。如果不拆分同一種房型有十間房房型價格要改時你得改十行拆開后只要改一行。標準做法是兩張表房間表通過外鍵引用房型表。CREATE TABLE room_type ( type_id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(50) NOT NULL COMMENT 房型名稱, bed_type VARCHAR(20) DEFAULT NULL COMMENT 床型, price DECIMAL(10,2) NOT NULL COMMENT 門市價, area INT DEFAULT NULL COMMENT 房間面積, max_people INT DEFAULT 3 COMMENT 可住人數(shù) ); CREATE TABLE room ( room_id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL COMMENT 房間號, floor INT DEFAULT NULL COMMENT 樓層, type_id INT, status TINYINT DEFAULT 0 COMMENT 0空閑 1已訂 2入住 3清潔/維修, FOREIGN KEY (type_id) REFERENCES room_type(type_id) );狀態(tài)status放在房間表而不放在房型表因為同一房型下不同房間狀態(tài)可能不同308在住、309空閑這很正常。這里要提醒一句訂單里的金額不要實時去關聯(lián)房型表算而是在下單那一刻把房型價格冗余到訂單表里。這是歷史快照因為過兩天房價可能調整老訂單的金額不能跟著變。3.2 訂單表設計訂單號、日期區(qū)間和沖突判斷邏輯訂單表是這個系統(tǒng)里最容易寫錯的一張表。先說兩個容易被帶偏的點一是主鍵自增id不要直接暴露給用戶當訂單號業(yè)務上要單獨給一個order_no字符串字段二是入住日期和離店日期用DATE類型不要用DATETIME因為房態(tài)按天算不按小時算。CREATE TABLE book_order ( order_id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 對外業(yè)務單號, user_id INT NOT NULL, room_id INT NOT NULL, check_in_date DATE NOT NULL COMMENT 入住日期, check_out_date DATE NOT NULL COMMENT 離店日期, order_amount DECIMAL(10,2) NOT NULL COMMENT 訂單金額下單時的房型價格快照, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已入住 3已退房 4已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_order_room_date (room_id, check_in_date, check_out_date), KEY idx_order_user (user_id) );這個系統(tǒng)最核心的一段SQL是“查可用房間”。要判斷某間房在2024-07-01入住、2024-07-03離店是否可用不是看它現(xiàn)在狀態(tài)是不是0而是看它有沒有“占房訂單”和這個日期區(qū)間重疊。區(qū)間重疊的判斷條件是已有訂單的入住日期 新訂單的離店日期且已有訂單的離店日期 新訂單的入住日期。SELECT r.* FROM room r WHERE r.status 0 AND r.room_id NOT IN ( SELECT o.room_id FROM book_order o WHERE o.status IN (0, 1, 2) -- 待支付、已支付、已入住都算占房 AND o.check_in_date 2024-07-03 -- 新訂單的離店日期 AND o.check_out_date 2024-07-01 -- 新訂單的入住日期 );這段SQL里的NOT IN子查詢是關鍵先取出所有“占房訂單”對應的房間再反查不在這個集合里的空閑房間。狀態(tài)過濾必須包含待支付因為待支付訂單雖然還沒付款但房間已經(jīng)被鎖定不能再賣給第二個人。邊界情況是已有訂單離店日期等于新訂單入住日期時不算沖突客人退房當天房子就能賣給下一位。3.3 索引、外鍵與刪除策略設計文檔里要寫清楚的規(guī)定索引方面上面DDL里已經(jīng)給book_order建了聯(lián)合索引(room_id, check_in_date, check_out_date)這段SQL正是沖突查詢用到的條件列。如果不建這個索引數(shù)據(jù)量一上去每次查可用房間都會全表掃描。status字段不單獨建索引因為它的區(qū)分度太低查1還是查4差別不大。外鍵要不要建我的習慣是“建但不依賴它做級聯(lián)操作”。房間表對房型表建外鍵訂單表對房間表建外鍵好處是防止誤刪——你刪一個已經(jīng)被訂單引用的房間時數(shù)據(jù)庫會攔你。設計文檔里必須寫明客房、訂單都屬于歷史數(shù)據(jù)物理刪除要禁止所有“刪除”都是邏輯刪除比如給房間加一個is_active字段或者把房型置為停用。訂單同理只做“取消”不做DELETE。最后是字符集。建庫語句統(tǒng)一用utf8mb4而不是utf8utf8mb4是完整的UTF-8實現(xiàn)能存生僻字和Emoji排序規(guī)則用utf8mb4_general_ci即可。這一步做完后面基本不會遇到中文亂碼省很多事。4. 把項目跑起來從解壓到Tomcat啟動的最小操作序列標題里寫了“源碼設計文檔部署說明視頻演示”說明壓縮包的內容是齊的。很多同學拿到手直接開IDEA就跑結果報錯一堆。這章按我的操作順序來每一步都對應一件事。4.1 解壓后先做的三件事看目錄結構、讀設計文檔、核對部署說明不要急著點運行。先解壓然后看四類東西源碼目錄里有沒有pom.xml判斷是不是Maven工程設計文檔確認業(yè)務表結構部署說明確認JDK、Tomcat、MySQL的版本要求視頻演示不用全看完拖動到登錄和預訂頁面看一眼預期效果即可避免自己跑通后不確定“什么樣算成功”。壓縮包內容你先確認什么源碼目錄是Maven結構還是普通Web工程入口在哪設計文檔數(shù)據(jù)庫有幾張表業(yè)務有哪些角色部署說明JDK/Tomcat/MySQL版本SQL腳本文件名視頻演示登錄賬號入口頁面長什么樣這個檢查本身不需要花很多時間但它能幫你避開“本地環(huán)境版本不對導致啟動失敗”這種最冤枉的問題。4.2 建庫、導入SQL腳本、修改數(shù)據(jù)庫連接配置數(shù)據(jù)庫這步是大多數(shù)人第一次卡住的地方。先打開部署說明找到SQL腳本文件的名字然后啟動MySQL客戶端建庫導入。mysql -u root -p -- 登錄后執(zhí)行 CREATE DATABASE hotel_db CHARACTER SET utf8mb4; USE hotel_db; SOURCE /path/to/hotel_db.sql;如果部署說明給的是獨立SQL文件也可以直接在系統(tǒng)命令行導入mysql -u root -p hotel_db /path/to/hotel_db.sqlSOURCE是MySQL客戶端內部的命令重定向是系統(tǒng)Shell的方式兩者效果一樣。導入后執(zhí)行SHOW TABLES;確認表的數(shù)量再SELECT * FROM book_order;看有沒有初始化數(shù)據(jù)。很多系統(tǒng)會把初始賬號寫在SQL腳本的INSERT語句里這一步能看到管理員賬號到底被設成了什么。接著改連接配置。SSM工程的數(shù)據(jù)庫配置一般在jdbc.properties或db.properties里jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/hotel_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password你的數(shù)據(jù)庫密碼driver取決于MySQL版本MySQL 5.x用com.mysql.jdbc.DriverMySQL 8.x用com.mysql.cj.jdbc.Driver用錯會報驅動類找不到。URL里的characterEncodingutf8解決中文寫入問題serverTimezoneAsia/Shanghai解決MySQL 8.x的時區(qū)報錯。password必須改成你本機的數(shù)據(jù)庫密碼這里填別人的密碼是連不上的。4.3 IDEA導入Maven工程、配置Tomcat、啟動驗證導入工程這步我的習慣是File → Open直接選源碼根目錄等右下角Maven依賴同步完成。如果依賴長時間下載不完成檢查Maven的本地倉庫配置和鏡像不要手動去網(wǎng)上一個個下載jar包。JDK版本按部署說明來一般切到1.8。dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.23/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.7/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.29/version /dependencypom里的版本號以工程自帶為準不要自己往高了換SSM對版本組合有兼容性要求換版本可能帶來預料外的報錯。配置Tomcat時在Run → Edit Configurations里添加Tomcat Server → LocalDeployment選項卡選war explodedApplication context填/或者部署說明里寫的項目名。啟動后打開瀏覽器訪問對應地址。驗證成功的標準是能看到登錄頁輸入SQL腳本里的初始賬號能進后臺打開客房列表能查到數(shù)據(jù)。這一步走通整個系統(tǒng)的運行鏈路基本沒問題了。5. 排錯與避坑數(shù)據(jù)庫連接、端口、靜態(tài)資源與中文亂碼的四類常見問題這一章寫的是我見過最多、也最好復現(xiàn)的幾類問題。每條按現(xiàn)象、原因、解決三步走建議把這一章當成排查手冊用遇到哪個查哪個。5.1 數(shù)據(jù)庫連不上Access denied 與時區(qū)亂碼現(xiàn)象一Tomcat啟動后訪問頁面后臺日志報Access denied for user rootlocalhost (using password: YES)。現(xiàn)象二報錯信息里出現(xiàn)The server time zone value й?后面跟著一串看不懂的亂碼。第一個原因是密碼不對或者數(shù)據(jù)庫沒建。注意區(qū)分Access denied代表用戶名密碼有問題Unknown database代表庫名不存在這兩個是不同的問題。先打開命令行手動執(zhí)行mysql -u root -p驗證能不能登錄再用SHOW DATABASES;確認hotel_db存在。第二個原因是連接串缺了serverTimezone參數(shù)MySQL 8.x默認時區(qū)跟系統(tǒng)不一致就會報這個錯。解決方式在jdbc.properties里把密碼改成你本機的真實密碼URL加上serverTimezoneAsia/Shanghai然后重啟Tomcat。改配置后只熱部署不重啟連接池里的舊連接不會重新初始化這是很多人改了配置但問題還在的原因。5.2 Tomcat起不來端口被占用現(xiàn)象IDEA控制臺報Port 8080 was already in use或者Error running Tomcat: Address already in use點擊啟動立刻失敗。原因是本機某個進程已經(jīng)占用了8080端口常見的是之前啟動過的Tomcat實例沒關干凈或者其他開發(fā)工具的服務占了這個端口。解決方式先找到占用進程再決定殺進程還是換端口。# Windows netstat -ano | findstr 8080 taskkill /PID 對應PID /F # Linux / macOS lsof -i:8080 kill -9 對應PID如果殺不掉或者那個進程不能動就改Tomcat端口。在conf/server.xml的Connector節(jié)點把port8080改成8081再次啟動后訪問地址也要同步改成http://localhost:8081/項目名/。這里順便說一句IDEA的Tomcat配置里也有一個HTTP port如果改了server.xml的端口IDEA里的端口也要同步改否則還會沖突。5.3 登錄頁沒有樣式CSS和JS全是404現(xiàn)象頁面能打開但只有一個光禿禿的HTML骨架控制臺里一堆/css/style.css 404之類的報錯。原因有兩個我遇到過很多次。第一是JSP里靜態(tài)資源路徑寫死了比如href/css/style.css部署后項目上下文路徑變了真實路徑變成/項目名/css/style.css所以404。第二是SpringMVC攔截器把靜態(tài)資源請求也攔了DispatcherServlet把.css文件當成Controller去匹配自然找不到。解決方式頁面里所有靜態(tài)資源路徑前面都加上${pageContext.request.contextPath}這是最穩(wěn)妥的寫法。然后在SpringMVC配置文件里放行靜態(tài)資源mvc:resources mapping/static/** location/static// mvc:default-servlet-handler/mvc:default-servlet-handler/是讓容器默認的Servlet去處理靜態(tài)文件沒有這一行Tomcat默認的靜態(tài)文件處理能力會被DispatcherServlet覆蓋掉。加了之后CSS、JS、圖片這類請求不再走業(yè)務邏輯訪問頁面的樣式問題就能解決。5.4 中文全變問號三處編碼必須一致現(xiàn)象頁面上輸入“張三”保存后到數(shù)據(jù)庫里看變成“???”。原因是寫入鏈路上有三處字符集不一致數(shù)據(jù)庫表、JDBC連接串、頁面請求編碼。三處只要有一處是latin1或者默認編碼中文就可能變問號。解決方式統(tǒng)一改成utf8mb4。先確認表本身的字符集SHOW TABLE STATUS LIKE book_order;看Collation列如果不是utf8mb4_general_ci執(zhí)行ALTER TABLE book_order CONVERT TO CHARACTER SET utf8mb4;。然后確認連接串里有characterEncodingutf8。最后在JSP頁面頭部加% page contentTypetext/html;charsetUTF-8 %。這三點都做到基本不會再出現(xiàn)中文亂碼。如果還有問題檢查Spring的CharacterEncodingFilter是否配置了它會統(tǒng)一處理請求和響應的編碼。6. 讓這個系統(tǒng)在答辯里站得住兩個實用的增量改進方向基礎功能跑通只是及格線。想讓評分或者面試官覺得你有想法可以在不改變整體架構的前提下加兩個有技術含量的改進點。這兩個方向工作量不大但能展示你對業(yè)務的思考深度。6.1 做一個“超時未支付自動取消”的任務酒店房間是庫存資源用戶占著訂單不付款房間就一直不能賣。常見的做法是訂單創(chuàng)建后30分鐘內未支付自動置為取消釋放房間庫存。SSM工程里用Spring Task就能實現(xiàn)。Component public class OrderTimeoutCancelTask { Scheduled(cron 0 */5 * * * ?) public void cancelExpiredOrders() { // 查出當前時間往前推30分鐘仍未支付的訂單批量置為已取消 // UPDATE book_order SET status 4 // WHERE status 0 AND create_time #{targetTime} } }這個任務用一條批量UPDATE就能完成不需要逐條查再逐條改。使用批量更新比循環(huán)更新效率高得多。別忘在Spring配置文件里加task:annotation-driven/開啟定時注解支持否則Scheduled不會生效。這個功能在現(xiàn)場演示時會很有說服力相當于用代碼解決了一個真實的業(yè)務問題。6.2 把預訂沖突檢測包裝成一個可講清楚的技術點查可用房間那段NOT IN邏輯是系統(tǒng)里最值得講的部分。答辯時可以直接把問題拋出來同一間房在同一個日期區(qū)間兩個人的下單請求同時打過來怎么辦。這段邏輯雖然能擋住“已經(jīng)被占的房間”但并發(fā)場景下兩個事務同時查到了同一間房可用的結果就可能產(chǎn)生重復訂單。常見的兜底方案有兩種。第一種是在業(yè)務代碼里對房間ID加鎖把“查詢可用房間插入訂單”兩步包在同一個事務里事務邊界要清晰。第二種是給訂單表加一個版本號字段做樂觀鎖更新時帶上版本條件更新影響行數(shù)為0就代表被別人搶先。這里不展開代碼但設計文檔里把這塊的并發(fā)處理思路寫清楚比堆很多頁面截圖更能體現(xiàn)水平。我自己的習慣是拿到這類工程先動手畫一張狀態(tài)流轉圖畫不清楚就說明沒看懂畫清楚了后面所有bug都有了一個判斷標準。把這個習慣帶進這個系統(tǒng)里你會發(fā)現(xiàn)兩套狀態(tài)、一張訂單表遠比一堆頁面更值得研究。希望幫到你。本文還有配套的精品資源點擊獲取