Front and rear end separation demo hotel management system

model design

  hotel management system, mainly related to check-in, check-out and room and guest information management; After analysis, the entities involved and the relationship between entities are extracted:

operation flow

Check in

Check out

Administration

Room information management

Guest information management

Page design

Check in

Check out

Administration

Room information management

Add rooms

Change room type

Bed management

Change subscribable status

Guest information management

functional design

Check in

Use background   the registration function is used when guests check in. They need to fill in the basic information of guests, check-in rooms, check-in dates and other information. When the main logic user fills in the guest information, the front end will check the validity of the corresponding data. The main checks include:

Check out

Use background   check out is used when guests check in and check out at the appointed time; The main logic     check out function is that the user first queries the guest room to be checked out through the conditions, and after confirming that the information is correct, click the check out button. The back end will calculate according to the check-in, check-out time and current house price. If the check-out is successful, the user's check-out result will be returned, including the guest's check-in time and room fee.

Administration

Room management

Use background   room management is used when adding rooms, modifying room types, managing beds, etc; The customer cannot be deleted because it will participate in a series of businesses. It is not allowed to delete and can be set to non bookable status; Main logic   first, all guest room information will be listed in pages, including the current status of guest rooms, room type, house price, number of beds, number of guests and total revenue, and can be sorted and filtered accordingly.   when the guest room is currently occupied, the room type and reservation status cannot be modified.    when the user clicks the add room button, a dialog box will pop up, fill in the room number and room type, and confirm the room inventory. Of course, the front end will require the room number and room type to be required, the back end will judge accordingly, and will judge whether the room number already exists. If it does not exist, add the default state of the room and add it. After the addition is successful, The front end will put the new room information returned by the back end into the list.    when the user clicks to change the room type, a dialog box will pop up. When the user selects the room type (hour room, day room and month room), the current latest price and validity period of these room types will be brought out (if there is no, the deadline will be 9999-12-31 23:59:59 by default). When the user selects the hour room, the validity period is accurate to minutes, and other room types to days. The user can change the current house price, The valid period can also not be changed. Confirm to save. The browser waits for the server to return the correct or error message, and then prompts accordingly. If successful, change the front-end room information to the latest information.    when the user clicks bed management, a dialog box will pop up. The user can add, modify and delete beds. If they are not saved, the front-end room information will not be affected. When confirming, the user will wait for the back-end processing to return and give corresponding message prompts. If successful, the front-end room information will be personalized, and if failed, it will not be modified;    when the user clicks the status switch of bookable and non bookable, it will request the server. At this time, the front end will wait. When the server returns success, it will modify the current status of the front-end guest room. If it fails, it will give a message without any modification;

Guest management

Use background   guest management is used when guest information needs to be modified or cleared; Cannot be used for new guests because new guests are added through the registration entrance. Mobile phone name mobile phone ID number: first, users should first check guest information according to their guest information, then change or delete. When guests are checking in, they are not allowed to delete (check both front and back). Modifications include modifying guest name, ID number, mobile phone number, ID card number and mobile phone number to conform to the corresponding check rules (both front and back check), and when stored, The back end will also determine that the ID number can not be the same as the other guest ID number, and update after the confirmation is correct. When requesting the server, the browser will wait until the server returns the result;

interface design

Interface Overview

  at present, there are two restful interface classes, one is the guest room interface and the other is the guest interface

   there is no separate interface for guest interface query, update and deletion, because the new guest information is realized through the guest room registration interface;    the interface of guest room includes query, addition and change. The query includes fuzzy query and query according to guest room ID, while the update essentially has three interfaces. One is the ordinary update interface. The fields with values in the guest room data structure are updated, and the null fields are not updated; The other two updates are registration and check-out. These two are special updates. Because the logic is too different from the ordinary update logic, they are taken out separately;

Return type

   the return types are unified as: responseentity    resultdto, including return success or failure ID, message code, message and data; Responseentity is spring's own class, which can be used to flexibly customize the returned httpcode; In this way, when an error message is returned, you can set httpcode to 400 or 500 instead of 200 to make the semantics consistent.    special cases: when the front end needs to directly use the returned results (for example, the automatic completion search box, the front end requests the server to directly obtain the results without encapsulation), such return types cannot be used;    the front end sends a request to the server through the service to uniformly process the returned results and HTTP error messages from the server without processing them in the component;

exception handling

   both front and rear exceptions are handled uniformly; The front end is handled in the service, and the back end is handled in a unified exception handling class; The exception handling class can handle exceptions and check exceptions in a unified way, including direct check of controller method parameters and check exceptions in dto, without judgment in each method body of controller;

development tool

Development technology

Online demonstration

click me

If there is anything unreasonable in the text, please point out! If it helps you, welcome star!

GitHub: https://github.com/Cool-Coding/angular-springboot-demo

Bug feedback and suggestions: https://github.com/Cool-Coding/angular-springboot-demo/issues