模型設計
旅館管理系統，主要涉及到登記入住，退房以及客房和客人信息管理；經過分析抽像出涉及到的實體以及各實體之間的關系：
可以看出整個業務以客房為中心，入住，退房，定價，收費都是以客房為基本單位，所以需要以客房為中心來設計各實體之間的關系。
我們來看一下，各實體中的字段以及各實體之間的關系圖:
業務流程
登記入住
退房
管理
客房信息管理
客人信息管理
頁面設計
登記入住
退房
管理
客房信息管理
增加客房
更改房型
床鋪管理
更改可預訂狀態
客人信息管理
功能設計
登記入住
使用背景
登記功能是當客人來辦理入住時使用，需要填寫客人的基本信息，入住客房以及入住日期等信息。
主要邏輯
用戶在填寫客人信息時，前端會對相應數據的有效性進行校驗，主要校驗包括：
-
填寫過程中需要對填寫的信息進行有效性校驗，比如身份證號/手機號等;
-
入住日期的選擇需要根據所入住的房型來決定是選擇到天還是到分鍾，而且選擇的日期不能晚於當天。
后端也會對進行有效性以及其它的一些判斷： -
也需要對傳入的身份證號/手機號進行相同校驗.
-
判斷入住的客房是否存在，所選的客房是否是不可訂,所選客房是否有床鋪和價格
-
身份證號的客人是否存在多個以及相同身份證號不能兩次登記入住同一房間等
還有一些鋪助功能，方便用戶使用，減少錯誤，提高效率: -
前端用戶在輸入客房號時，會有一個下拉幫助框，顯示客房的狀態，房型等信息，有助於用戶簡間明了解所入住客房狀態；
-
當用戶選擇的是已經有客的客戶時，日期則變為灰色，自動顯示客房當前的入住和退房時間，不可更改。
-
客房號在登記時，不會顯示不可訂狀態的客房；
請求到達服務器后，在判斷數據合法后，查詢入住的客房信息，將其添加進客房信息中，然后保存(客房-客人關系由客房維護)；
退房
使用背景
退房是客人登記入住后，到時間后退房使用；
主要邏輯
退房功能首先是用戶通過條件查詢到需要退的客房，確認信息無誤后，點擊退房按鈕，后端會根據入住，退房時間以及當前房價進行計算，如果退房成功，則返回用戶退房結果，包括客人入住的時間以及房費。
管理
客房管理
使用背景
客房管理是當新增客房，修改房型，管理床鋪等時使用；不能刪除客戶，因為客戶會參與到一系列的業務中，不允許刪除，允許置為不可預訂狀態；
主要邏輯
首先會分頁列出所有客房信息，包括客房當前狀態，房型，房價，床鋪數，客人數以及總收入，並可進行相應排序與篩選。
客房當前有客時，不可以修改房型與可預訂狀態。
用戶點擊新增客房按鈕時，會彈出對話框，填寫客房號以及房型，確認房存，當然前端會要求房號和房型必填，后端也會進行相應判斷，而且還會判斷客房號是否已存在，如果不存在，則添加客房默認狀態，並新增，新增成功后，前端會將后端返回的新客房信息放入列表中。
用戶點擊更改房型時，彈出對話框，用戶選擇房型(小時房、天房、月房),會帶出這幾個房型當前最新價格以及有效期(沒有，則截止日期默認為9999-12-31 23:59:59)，當用戶選擇小時房時，有效期精確到分鍾，其它房型到天，用戶可以更改當前房價，有效期間也可以不更改，確定保存，瀏覽器等待服務器返回正確或錯誤的消息，然后進行相應提示，如果成功，則更改前端客房信息為最新信息。
用戶點擊床鋪管理時，彈出對話框，用戶可以進行新增，修改，刪除床鋪，如果沒有保存，則不會影響前端客房信息，確定時會等待后端處理返回，並給出相應消息提示，成功則個性前端客房信息，失敗則不修改；
用戶點擊可預訂與不可預訂狀態開關時，會請求服務器，此時前端會等待，當服務器返回成功時，才修改前端客房當前狀態，失敗則給出消息，不做任何修改；
客人管理
使用背景
客人管理是當需要修改或清理客人信息時使用；不能用於新增客人，因為新增客人通過登記入口添加。
主要邏輯
用戶首先根據客人信息模糊查詢客人信息，然后進行更改或刪除，當客人當前正入住時，則不允許刪除(前后端都校驗),修改包括修改客人姓名，身份證號，手機號，身份證號和手機號要符合相應的校驗規則(前后端都校驗),而且在保存時，后端還會判斷身份證號不能與現在其它客人身份證號相同，確定無誤后進行更新；在請求服務器時，瀏覽器會等待直到服務器返回結果；
接口設計
接口概覽
目前restful接口類共有兩個，一個是客房接口，一個是客人接口
其中客人接口查詢，更新，刪除，沒有單獨的增加接口，因為新增客人信息是通過客房的登記接口實現；
客房的接口包括查詢，新增，更改，其中查詢有模糊查詢和根據客房ID查詢，而更新實質上有三個接口，一個是普通的更新接口，客房數據結構中有值的字段更新，null的字段則不更新；其它兩個更新一個是登記，一個退房，這兩個是特殊的更新，因邏輯與普通更新邏輯相差太大，所以單獨拿出來；
返回類型
返回類型統一為：ResponseEntity
ResultDto 包括返回成功失敗標識，消息碼，消息，數據；ResponseEntity是Spring自帶的類，使用它可以靈活自定義返回的HttpCode；這樣當返回錯誤消息時，可以設置HttpCode為400或500等，而不是200，使語義一致。
特殊情況：前端需要直接使用返回的結果情況下(比如自動補全搜索框，由前端請求服務端，直接得到結果，不需要封裝)，不能使用這樣的返回類型；
前端通過service向服務器發起請求，統一處理服務器返回結果以及http錯誤消息，不用再到component中處理；
異常處理
前后端異常都是統一處理；前端是在service中處理，后端在統一的異常處理類中處理；異常處理類可以處理異常，還可以統一處理校驗異常，包括controller方法參數的直接校驗以及dto中的校驗異常，不用在controller每個方法體中判斷；
開發工具
- webstorm
- Intellij Idea
開發技術
| 名稱 | 框架 | 版本 |
|---|---|---|
| 前端框架 | angular | ^6.0.3 |
| UI框架 | ng-zorro-antd | ^1.1.1 |
| Web框架 | springboot | 1.5.14.RELEASE |
在線演示
如果文中有什么不合理的地方，請指出！如果對您有所幫助，歡迎Star！
GitHub: https://github.com/Cool-Coding/angular-springboot-demo
bug反饋及建議:https://github.com/Cool-Coding/angular-springboot-demo/issues