目录
如需链接的小伙伴pc端请点击👉👉👉资源
移动端请点击👉👉👉请点击
1 系统简介
2 系统相关技术
2.1 Java技术
2.2 SSM框架
2.3 MySQL数据库
3 需求分析
3.1 系统介绍
3.1.1 系统概述
3.1.2 系统面向的用户群体
3.1.3 系统范围
3.1.4 系统中的角色
3.2 可行性分析
3.2.1 技术可行性
3.2.2 经济可行性
3.2.3 操作可行性
3.3 系统功能需求
3.4 系统用例
3.4.1 系统用例图
3.4.2 用例规约
4 系统设计
4.1 系统架构设计
4.2 系统时序分析
4.2.1 动态管理
4.2.2 房间管理
4.2.3 订单管理
4.2.4 用户管理
4.2.5 数据统计
4.2.6 房间预订
4.3 系统数据库设计
4.3.1 概念结构设计
5 系统实现
5.1 系统模块汇总
5.2 用户功能的实现
5.2.1 民宿动态
5.2.2 房间查询
5.2.3 房间详情
5.3.4 预订房间
5.3.5 我的订单
5.3 管理员功能的实现
5.3.1 订单管理
5.3.2 管理员管理
5.3.3 用户信息管理
5.3.4 房间信息管理
5.3.5 民宿动态管理
5.3.6 统计
6 总结
1 系统简介
本系统对民宿管理进行了设计与实现。系统分为用户预订端和后台管理端。用户模块的功能以查询并预订房间为核心，再加上登录注册以及收藏、浏览公告等功能。管理者模块主要功能有管理员管理、用户管理、房间管理、民宿动态管理、日志管理，以及统计等功能。
本民宿管理系统设计与实现是基于B/S架构的，采用Java语言和JSP语言来开发，使用了SSM框架，用MySQL数据库来存储数据。本系统还存在一些不足之处，功能还需进一步丰富。但基本能够满足民宿管理的需求，同时降低了耦合度，便于后期维护。
2 系统相关技术
2.1 Java技术
多年以来，Java一直都是深受业内人士喜爱的编程语言。它具有面向对象的特点，让人们免去一些繁琐且无意义的工作，节省开发人的时间和精力。
Java是Web服务端目前使用最为广泛的编程语言之一。它将现实中的一些信息的特点和过程进行抽取，通过继承的结构将对象联系起来，使得开发代码的时候只需要关注对象本身的属性和方法，简化开发。
2.2 SSM框架
SSM框架是Java的一个常用框架，它的每个部分的职责互不干扰。它将代码分层，使模块解耦，也使得代码更加方便开发。
使用SSM框架后，无需再频繁手动创建对象，而是把这些都交给框架容器去处理，简化开发过程。框架中集成了多种功能模块，致力于Java EE编程领域各层的解决方案。
2.3 MySQL数据库
MySQL是一个关系型数据库管理系统。它所创建的表可以分别存储信息并且相互关联，从而降低了每张表的大小，使得数据的存储更加灵活、对数据的操作速度更快。
由于它是关系型的表存储方式，可以在有必要的时候重新创建一张表，将这张表与已存在的表关联起来，充分发挥扩展性强的特点。另外，该数据库在存储数据的时候会将本地数据文件加密，使数据安全存储。
3 需求分析
3.1 系统介绍
3.1.1 系统概述
本系统以预订房间和管理民宿信息为核心，目的在于帮助管理者科学规范且高效地管理民宿，节省人力物力、提高效益。
为了能够帮助管理，系统具有这些特点：系统界面色彩柔和、布局合理；有合理的权限分配以及数据的保护机制，确保数据准确安全；能够直观地、准确地反映民宿资源和收入等数据，方便管理者了解民宿经营情况，作出合适的规划。
3.1.2 系统面向的用户群体
系统一般是由顾客和管理者使用的。
顾客（普通用户）：即需要租住民宿房间的顾客，他们能够通过预订系统预订房间，进行相关操作。
管理者：包括民宿房东和民宿工作的管理员。他们通过系统管理民宿资源和信息，管理房间和处理订单等。
3.1.3 系统范围
系统基于B/S，使所有使用者都能够在连接网络的设备上通过网页使用系统功能，最大程度达到数据共享，满足系统用户需求。
基于Web的民宿管理系统分为前台和后台系统。开发的民宿管理系统面向的是民宿的工作人员和客户，其功能包括前台用户的登录注册、查询房间、房间预订、收藏房间以及订单管理等信息的处理，包括管理员对房间、订单和日志以及可视化统计等功能模块的管理，能够满足民宿管理者和顾客对系统的使用和需要。
3.1.4 系统中的角色
经过分析，从本民宿管理系统中提取出三种角色，分别是用户、房东、管理员。本系统的角色和其职责如表3-1所示。
表3-1 角色及其职责表
角色名称 | 职责描述 |
房东 | 房东在系统中拥有最大权限，能够最大限度地管理信息 |
管理员 | 管理员的职责与房东类似，但没有管理员信息管理的权限 |
用户 | 用户主要可以查询并预订房间，以及与之相关的一些操作 |
3.2 可行性分析
3.2.1 技术可行性
通过分析以上的系统需求，进而对技术进行分析。首先需要使用数据库存储各种数据，包括用户数据、房间信息、订单信息等。其次，需要使用到前后端交互技术，包括SSM框架以及HTML、CSS和JavaScript三大技术。这些技术条件基本都可以达到，技术可行性是没有问题的。
3.2.2 经济可行性
经过分析，本次开发系统需要使用的一些工具基本是开源的，而且由于系统本身不算大，对设备的配置没有很高的要求，日常使用的计算机就可以完成系统的开发和运行。因此，从经济方面考虑，没有问题。
3.2.3 操作可行性
由于系统的特点，在操作方面不会繁琐。在使用系统时，不需要进行复杂的操作，根据引导输入相关信息即可，其他的逻辑处理由系统本身完成。而且，目标客户都有一定的智能设备的使用经验，能够轻松地使用系统。
3.3 系统功能需求
在对本系统进行了业务逻辑分析后，明确了本系统分为用户预订端和后台管理端的设计。
用户端模块：由客户使用。用户模块的功能以查询并预订房间为核心，再加上登录注册以及收藏、浏览公告等功能。功能详情如下。
(1) 系统注册和登录：在正式使用本系统时需要登录才能进行租房操作。登录或注册需要查询数据库验证是否合法，并给出提示信息。此模块包含忘记密码功能。
(2) 房间查询：用户可以浏览和通过筛选条件查询房间信息，在登录后可以进行预订和收藏房间等操作。
(3) 预订：用户在登录后可以在房间详情页预订房间，预订时需填写个人信息、选择预订日期。
(4) 订单管理：可以取消订单或结算付款。取消订单不影响同一房间资源同一日期的再次预订；付款成功可以到线下办理入住。
(5) 个人信息：用户可以在这里改个人信息。
(6) 民宿动态信息：用户可以了解民宿动态，合理规划行程和住宿。
(7) 我的收藏：用户在登录后可以收藏喜欢的房间，在我的收藏页面可以看到已收藏的房间。
后台管理端模块：由管理者使用，其中，管理者包括房东和管理员，两者的功能职责稍有区别，房东拥有最高权限。管理者登录后主要功能有管理员管理，用户管理，房间管理，民宿动态管理，日志管理，以及统计功能。
(1) 登录：管理员使用系统时需要登录。管理员账户由房东（老板）添加。
(2) 管理员信息：房东可以管理自己和低级别管理员的信息，此功能只对房东开放。
(3) 用户信息管理：管理员可以管理顾客的账号，仅限于查看不敏感数据和删除功能。
(4) 订单管理：展示和操作订单信息。
(5) 房间管理：管理者在这里管理房间资源信息。
(6) 动态管理：管理公告等动态信息，用户端可以查看到这些动态信息。
(7) 日志管理：主要为登录日志，日志在用户登录时自动添加。此处提供删除按钮。
(8) 统计：对民宿经营信息进行统计。主要是两方面的统计：房源信息统计和收入情况统计。房源统计包括不同房型的数量、面积等统计；收入统计包括不同时期、不同房型的收入情况的展示。
根据分析，可以确定系统的功能模块信息，如图3-1所示。
图3-1 系统功能模块图
3.4 系统用例
3.4.1 系统用例图
通过系统用例分析，外部参与者可以看到系统的功能[14]。在分析之后，明确了系统包含前台和后台，前台主要包括搜索并预订房间等，后台管理模块主要是对民宿信息的管理，包括房间的管理、用户管理以及统计等。系统的总用例图如图3-2所示。
图3-2 总用例图
管理者包括房东和管理员，登录后可以管理用户、房间、动态、订单和日志，可以查看统计信息。其中房东另外有对管理员操作的功能。管理者用例图包括房东和管理员的用例，如图3-3所示。
图3-3 管理者用例图
用户可以查看网站信息，包括查询房间、预订房间、民宿动态、注册登录、个人资料、我的订单、收藏。用户用例图如图3-4所示。
图3-4 用户用例图
3.4.2 用例规约
房间添加用例规约如表3-2所示。
表3-2 房间添加用例规约
说明项 | 备注 |
用例名称 | 房间添加 |
简要说明 | 管理员在系统上添加民宿房间资源 |
主角 | 已登录的管理员 |
基本流 | 1.登录进入主页面，点击房间信息管理 2.点击添加，进入新增界面 3.输入正确的信息，然后提交 4.房间添加成功，弹窗提示 5.关掉提示信息，跳转原来页面 |
备选流 | 当基本流3发生后，若房间添加失败，弹窗提示，然后跳转到房间列表展示页面 |
特殊需求 | 无 |
前置条件 | 管理员成功登录系统 |
后置条件 | 房间添加成功 |
扩展点 | 无 |
房间预订用例规约如表3-3所示。
表3-3 房间预订用例规约
说明项 | 备注 |
用例名称 | 房间预订 |
简要说明 | 指顾客选择喜欢的房屋下单 |
主角 | 已注册并登录的用户 |
基本流 | 1.用户登录进入首页，点击立即找房，浏览房间信息 2.点击自己喜欢的房屋 3.如果打算预订，点击预订按钮 4.页面跳转至下单界面，输入信息并选择日期然后提交 5.页面跳转到订单页面，此时显示未付款状态 6.点击支付来完成订单 7.在入住前，也可以取消订单 |
备选流 | 当基本流5发生后，用户未选择付款，之后可以自行去我的订单页面付款 |
特殊需求 | 无 |
前置条件 | 用户成功登录系统 |
后置条件 | 房间预订成功 |
扩展点 | 无 |
4 系统设计
4.1 系统架构设计
该系统采用B/S架构和SSM框架，主要分为四个层次：视图层、控制层、服务层、数据持久层。系统架构图如图4-1所示。
图4-1 系统架构图
视图层：视图层用来显示本系统的界面以及与控制层数据交互。采用了Bootstrap和ECharts等一些框架和插件。
控制层：用来接收页面提交的数据，自动封装，并发送给服务层。
服务层：接收传来的数据，在进行业务处理后，调用数据持久层对数据库进行查看或修改等操作。
数据持久层：将传来的数据保存到本地库中，或者用来查询相关内容。
其他服务组件：为系统的运行提供基础条件。
以上各层组成了完整的整体，保证了系统的运行。
4.2 系统时序分析
4.2.1 动态管理
此处以添加动态为例。系统引入了编辑器插件，功能丰富。管理者在编辑内容时，如果有附件信息，自动上传附件，在提交后会把相关信息录入数据库，最终把操作结果返回到页面。
动态的添加可以用时序图来描述，如图4-2所示。
图4-2 动态添加时序图
4.2.2 房间管理
这里以添加房间功能为例进行描述。对于民宿管理系统来说，房间信息的添加是基本功能，帮助管理者在系统中录入新的房间信息。
房间添加的时序图如图4-3所示。
图4-3 添加房间时序图
4.2.3 订单管理
订单管理包括办理入住和取消等功能。用户在预订房间后管理员这里才会有订单生成。此处以订单的展示为例。调用订单管理功能时，系统会先向数据库查询订单数据，然后将数据展示在浏览器。
订单展示的时序图如图4-4所示。
图4-4 订单展示时序图
4.2.4 用户管理
房东能够对管理员和用户进行管理，能够更改管理员的信息，对于用户只有查看和删除权限。
这里以删除用户信息为例。页面会列出所有的用户。在删除用户时，将对应的编号传入后台，然后执行删除语句。
删除用户的时序图如图4-5所示。
图4-5 删除用户时序图
4.2.5 数据统计
适当的统计能够帮助管理者清晰明了地掌握民宿的经营信息，以此为依据对民宿的经营管理做出合适的调整。本系统的统计包括对房型和收入的统计。这里以收入统计为例。主要就是向数据库查询相关信息进行数据处理，随后将处理过的数据以图表形式展示。
收入统计的时序图如图4-6所示。
图4-6 收入统计时序图
4.2.6 房间预订
用户在前端可以预订房间，预订时进行账号验证。登录后才可以进行预订。预订房间时需要填写完整的正确的信息才能预订成功。
房间预订的时序图如图4-7所示。
图4-7 房间预订时序图
4.3 系统数据库设计
数据库对于信息系统来说有重大意义，想要完成一个优秀的项目首先要设计好数据库。数据库是系统的根本，系统的重要数据几乎都在其中存储。一个好的数据库能够使系统性能优越，也能使数据的安全得到保障。
4.3.1 概念结构设计
数据库概念模型可以将现实存在的一些数据抽象到数据库，从而做到信息世界的建模。本文采用E-R模型法来设计。
根据系统的功能模块划分，抽象出实体大概有七类，分别是管理员类、用户类、房间类、日志类、动态类、收藏类、订单类。整体的E-R图如图4-8所示。
图4-8 整体E-R图
详细分析了本系统中大部分的实体，本系统的各基本实体属性图如下。
(1) 管理员具体有六个属性。分别是编号、电话、类型、姓名、密码和用户名。
管理员实体属性图如图4-9所示。
图4-9 管理员实体属性图
(2) 收藏实体具有这些属性：编号、房间id和用户id。
收藏实体属性图如图4-10所示。
图4-10 收藏实体属性图
(3) 民宿动态实体具有这些属性：编号、名称、描述、操作时间。
民宿动态实体属性图如图4-11所示。
图4-11 民宿动态实体属性图
(4) 房屋实体具有这些属性：编号、房间编号、名称、添加时间、图片、租金、室型、朝向、户型、面积、出租类型、区域、地址、房主名字、电话、标签和状态。
房屋实体属性图如图4-12所示。
图4-12 房屋实体属性图
(5) 订单实体具有这些属性：编号、用户编号、房间编号、租金、描述、下单时间、附件、状态、开始时间、租住天数、结束时间、姓名、身份证号、电话和房间id。
订单实体属性图如图4-13所示。
图4-13 订单实体属性图
(6) 用户实体具体是这些属性：编号、姓名、用户名、密码等。
用户实体属性图如图4-14所示。
图4-14 用户实体属性图
(7) 日志实体具有这些属性：编号、用户名、信息以及操作时间。
日志实体属性图如图4-15所示。
图4-15 日志实体属性图
5 系统实现
5.1 系统模块汇总
本民宿管理系统分为用户端和后台管理端，系统的模块汇总表如表5-1和表5-2所示。
其中表5-1是用户预订子系统的模块汇总，包含了用户可以操作的功能。
表5-1 用户预订模块表
模块名称 | 功能简述 |
注册登录 | 登录后可以预订、支付等 |
房间查询 | 用户登录前可以浏览房间，登录后可以预订 |
预订 | 用户登录后可以预订，需要填写相关信息 |
订单管理 | 可以查看订单记录，进行取消订单或结算付款操作 |
个人信息 | 查看或修改个人基本信息 |
我的收藏 | 可以在这里查看已经收藏的房间 |
民宿动态信息 | 了解民宿动态 |
表5-2是后台管理子系统的模块汇总，管理员用该子系统来管理民宿。
表5-2 后台管理模块表
模块名称 | 功能简述 |
登录 | 登录后可以使用系统 |
管理员信息 | 老板（房东）级别可以管理管理员信息 |
用户信息 | 工作人员能浏览和删除普通用户 |
订单管理 | 进行取消订单、顾客入住、退房等操作 |
房间管理 | 对民宿的房间资源进行管理 |
动态管理 | 管理公告等动态信息 |
日志管理 | 工作人员能够浏览或删掉日志 |
统计 | 对民宿经营信息进行可视化统计 |
5.2 用户功能的实现
用户可以浏览网站页面，包括找房、预订、查看公告等。其主页如图5-1所示。
图5-1 网站主页图
5.2.1 民宿动态
民宿动态会展示管理员发布的动态信息，如公告。用户可以点击民宿动态查看民宿动态信息，用以规划住宿行程。如果有动态信息，会显示动态；如果没有动态数据，友好提示用户。另外，点击链接会跳转页面浏览具体内容。
(1) 本模块的具体设计
本模块需要后台向数据库查询动态信息，需要用到share民宿动态表。
此模块的功能操作较为简单。用户点击查看民宿动态后，浏览器向控制层发送请求，随之后台向数据库查询数据，最终查询到的结果原路返回到浏览器。如果查询到动态信息，浏览器将数据列表显示在界面，用户此时可以点击动态列表来查看详情。如果查不到数据，提示用户没有信息。
民宿动态的功能流程图如图5-2所示。
图5-2 民宿动态功能流程图
(2) 其运行界面如图5-3所示。
图5-3 民宿动态界面
5.2.2 房间查询
房间查询页面可以向用户展现系统的房间资源。用户可以输入条件进行包括模糊查询在内的多条件查询，并且用户选择的条件会在查询后仍然显示在页面，避免每次重输。在房间列表上显示房间面积、价格等信息，方便用户初步了解房间，进行筛选。
(1) 具体设计
用户第一次进入页面时，查询条件为空，将会列出所有房间供用户浏览。输入信息后，会根据输入或选择的内容向数据库综合查询。最终将查询的结果展示给用户。
本模块需要向数据库查询房间的信息，用到的数据表有：house房间表。
功能流程图如图5-4所示。
图5-4 房间查询流程图
(2) 其界面如图5-5所示。
图5-5 房间查询界面
5.2.3 房间详情
房屋详情界面用来帮助用户尽可能地了解房间的信息。其中，图片能够直观地反映房间情况，还有房型和面积等基本信息也必不可少。另外，在详情页面，提供了收藏和预订入口，用户可以进行收藏、预订操作。
(1) 具体设计
本模块需要向数据库查询房间的详细信息和收藏情况，用到的数据表有：house房间表、shoucang收藏表。
本模块的功能流程是这样的。用户在浏览房间时点击某一房间，浏览器将该房间的id传入后台，后台根据此id向数据库查询房间的详细信息，如果已登录，同时查询该用户是否收藏该房间，然后将数据返回给浏览器，浏览器跳转到房间详情页面展示。如果用户已经登录并且收藏了此房间，右上角会显示“已收藏”，反之显示“收藏”两个字。本模块的功能流程图如图5-6所示。
图5-6 房屋详情功能流程图
(2) 其界面如图5-7所示。
图5-7 房屋详情界面
5.3.4 预订房间
在下单页面会展示房间的部分信息，但不可修改。用户需要选择租住时间，已过日期不可选择，房间已被预订的期间不可选择，并且结束日期需在开始日期之后。另外，必须填写自己相关信息才可下单。
(1) 模块具体设计
本模块首先需要查询房间信息，然后将订单写入数据库，因此用到house房间表和torder订单表。
用户在房间详情页点击预订会进行登录验证，没有登录会跳转登录页面，登录后才可以下单，下单页面会根据该房间的id展示房间的关键信息。用户在下单页面点击日历选择合适的日期，填写所必须的内容后可以下单。后台创建订单，将相关数据存储并返回提示信息。然后在我的订单里面，可以支付或取消订单。
功能流程图如图5-8所示。
图5-8 预订功能流程图
(2) 其界面如图5-9所示。
图5-9 预订界面
5.3.5 我的订单
此页面展示用户的订单信息，其中租金是根据单价和租住天数计算出的最终价格。另外，根据订单状态提供不同的功能操作，例如支付、取消功能。用户也可以在这里点击房间链接跳转到房间详情页。
用户点击支付或取消都会向后台发出请求，改变数据库数据，然后会刷新此页面。
此模块涉及的数据表为torder订单表。
其界面如图5-10所示。
图5-10 我的订单界面
5.3 管理员功能的实现
5.3.1 订单管理
订单管理界面分页展示每个订单的信息，包括租客的信息、房间信息等。同时会根据订单状态有选择地提供入住、退房和删除等操作按钮，管理者可以进行相关操作改变订单状态。
(1) 模块具体设计
此模块涉及torder订单表。
管理者进入订单页，后台向数据库按页码查询数据，显示在页面上。与此同时，系统判断订单状态，提供相应功能：如果订单未支付，显示取消和删除按钮；如果订单状态是已支付，显示删除、入住和取消按钮；如果订单状态是已入住，显示删除和退房按钮；如果是已退房，提供删除按钮。
订单管理的功能流程图如图5-11所示。
图5-11 订单管理功能流程图
(2) 其界面如图5-12所示。
图5-12 订单管理界面
5.3.2 管理员管理
此功能不对一般管理员开放。仅房东（老板）可以有管理员管理功能。系统会根据登录账号的权限提供不同的功能。页面不显示账号的密码，房东可以添加、修改和删除管理员，可以编辑自己的信息，但不允许编辑、删除与自己权限相同的账户。
此功能需要查询管理员账户，用到管理员表。
其界面如图5-13所示。
图5-13 管理员管理界面
5.3.3 用户信息管理
此页面分页显示普通用户的账号信息，但不涉及个人敏感信息。此处只提供查看和删除功能。在对业务功能及其性质的分析后，确定此处不支持对普通用户的添加和编辑，仅能用户自行注册账户和修改信息。
此模块会向用户表查询信息进行展示，因此要用到用户user表。
其界面如图5-14所示。
图5-14 用户信息管理界面
5.3.4 房间信息管理
此模块用于管理房间。在添加房间时需填写房间名称、地址、租金和房东等基本信息。也需要上传房间展示图片，图片会被上传保存防止丢失。查询和删改管理时，系统都会根据房间id进行操作，确保数据的正确性。
此模块可对房间表进行增删改查操作，因此本模块需要用到house房间表。
本小节的功能流程以添加房间为例。管理者在页面调用添加功能，会在页面中间出现添加窗口。管理者在此窗口填写房间的信息，信息需填写完整，同时上传房间图片。若未完整填写信息，弹出提示框。待信息校验合法后，将房间信息添加到数据库，返回处理结果。
房间添加功能流程图如图5-15所示。
图5-15 房间添加功能流程图
房间添加的运行界面如图5-16所示。
图5-16 房屋添加界面
5.3.5 民宿动态管理
此模块提供民宿动态的添加、查看和删改功能。其中，添加和编辑功能用到了百度的编辑器插件，管理者使用该编辑器编辑内容的同时，可以对内容的样式进行编辑，包括图片和文本的编辑。向后台提交数据时会把HTML标签和内容一同发送，数据库把这些数据作为一个字符串一并保存。这样也方便了页面的展示。
此模块涉及动态的增删改查，需要用到share民宿动态表。
其管理界面如图5-17所示。
图5-17 民宿动态管理界面
5.3.6 统计
管理员可以对房源、收入进行统计，房源统计包括不同房型的数量、面积等统计；收入统计包括不同月份、不同房型的收入情况的展示。
(1) 对于房型的统计涉及两方面的内容：房型的数量、面积和价格。
其中房型的数量统计采用环形图展示，在环形图中，不同的房型用不同的颜色表示。通过环形图中不同色彩的百分比，可以清晰的了解房型的数量比重，将鼠标放在图上可以查看该房型的数量。房型数量统计如图5-18所示。
图5-18 房型数量统计图
关于不同房型的面积和价格统计展示在同一折线统计图上。系统首先查出所有房间的面积和价格信息，根据房型分组统计，最终将整理好的数据展示在浏览器页面。使用折线图的优点在于能够根据房型的变化，直观地反映出面积和价格的变化趋势。其统计图如图5-19所示。
图5-19 面积和价格统计图
(2) 收入统计对于民宿管理者来说尤为重要，管理者可以根据这些便捷地掌握民宿经营情况，据此作出合理的规划。在这里，主要针对不同房型和日期做出统计。
关于收入统计，主要向管理者展示不同房型和日期的订单数和营业额。
收入统计主要采用柱形图来展示数据，方便管理者对于营业信息有一个直观的了解。其中特别的是，对于每个月份的营业额，采用折线图的统计方式，帮助管理者掌握不同月份的收入升降趋势。其统计图如图5-20所示。
图5-20 收入统计图
统计模块需要向数据库查询房型、面积、价格、订单数和收入等信息，因此需要用到house房间表和torder订单表。
6 总结
随着信息时代的发展和人们对高质量生活的追求，有更多的人喜欢上个性化的民宿，民宿经营的信息化已经成为了趋势和潮流。本系统是一个基于B/S架构的民宿管理系统，实现了浏览器页面和后台服务器端的开发。系统使用了SSM框架和MySQL数据库等技术，较大程度上降低了各模块的耦合度，以便于后期维护和升级。
源码+过程性文档+论文
