摘要
随着羽毛球在国内的普及程度越来越高,场馆运营方也遇到了预约混乱、使用登记效率低、商城管理分散等诸多的业务问题。传统的依靠人工电话或者线下登记的方式来完成预约的工作,不能够及时地了解到场地的使用情况,也无法对会员的权益以及订单的流转进行有效的管理,从而极大地阻碍了场馆的精细化运营水平。本文就上述问题设计并实现了一个基于Vue和SpringBoot的羽毛球场馆运营管理系统。系统使用前后端分离的架构,后端用SpringBoot搭建RESTful服务,前端用Vue创建响应式的界面,数据持久层使用MySQL数据库。系统以管理员和普通用户两个角色为主,包含场地信息管理、场地时段管理、场馆预约管理、使用登记管理、在线商城、订单管理、会员购买、新闻资讯等主要功能模块。经过功能测试验证,各个模块的业务流程闭环完整,数据交互准确稳定,达到设计要求,可以给同类型的体育场馆信息化建设提供一定的参考和借鉴。
关键词:羽毛球场馆;SpringBoot;Vue;预约管理;前后端分离
Abstract
The widespread popularity of badminton in China has placed mounting operational pressure on venue managers, who commonly struggle with disorganized booking processes, inefficient usage registration, and fragmented mall management. Traditional appointment models that rely on manual telephone calls or on-site paper-based registration fail to provide real-time visibility into court occupancy, and lack the capacity to unify membership entitlements and order workflows under a coherent management framework.
This paper presents the design and implementation of a badminton venue operation management system built upon Vue and Spring Boot. The system adopts a front-end and back-end separated architecture, in which the Spring Boot framework provides RESTful services on the server side, the Vue framework delivers a responsive user interface on the client side, and MySQL serves as the persistent data storage layer. Centered on two user roles, namely administrators and ordinary users, the system encompasses core functional modules including venue information management, time-slot management, venue reservation management, usage registration management, online mall, order management, membership purchase, and news information browsing.
Functional testing confirms that business workflows across all modules form complete closed loops with accurate and stable data interaction, meeting the intended design objectives. The system is expected to serve as a practical reference for the informatization of similar sports venues.
Key words:Badminton Venue; Spring Boot; Vue; Reservation Management; Front-end and Back-end Separation
第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
体育产业政策不断推进使得全民健身的需求被不断激发出来,羽毛球属于参与门槛低、场地需求弹性大的运动项目,在各种体育场馆里所占的比例较高。但是目前大多数羽毛球场馆在运营管理上还处在比较粗放的状态,场地预约依靠人工接听电话或者微信群通知,使用登记靠工作人员手工填写台账,商品销售和会员信息各自独立管理,没有实现数据互通。割裂式的管理方式在客流高峰时很容易造成场地冲突、订单遗漏等各类问题,大量的无效人工协调工作耗费了场馆运营成本。就技术发展来说,Web应用开发框架日趋成熟,大大降低了中小型场馆创建信息化管理系统的技术门槛[1]。国内外学者对于预约系统的研究已经取得了不少成果,从高校机房预约到医院检查预约,信息化手段在资源调度方面所具有的优势也得到了充分的证明[2]。SpringBoot框架依靠约定优于配置的思想大大缩减了服务端开发时间,Vue框架用组件化前端开发的方式把界面和逻辑解耦了,两者结合成了目前JavaWeb系统开发的主要技术路线[3]。在这种情况下,为羽毛球场馆设计出一套包含预约、登记、商城、会员等全部业务流程的运营管理系统,既符合技术条件所允许的现实情况,又是场馆进行精细化运营转型的必然要求。
1.1.2 研究意义
羽毛球场馆运营管理系统的建立,在操作流程上可以将原来分散在各个渠道的预约申请集中到后台统一处理,管理员可以在后台随时了解各个时间段场地被占用的情况,防止由于信息不对称造成重复预约或者资源浪费。用户不需要打电话或者到现场排队,在系统中就可以完成场地的选择、时段的确认、订单的生成等操作,整个操作路径比传统的模式要短很多。使用登记模块把入场记录变成数字形式,历史数据可以追溯,管理员依据此可对高峰时段做出合理的安排,从而提高场地的利用率。会员体系的数字化管理把折扣权益与订单结算联系起来,从而降低了由于人工核查而造成的差错风险。从行业角度来讲,该系统给体育场馆赋予了完备的信息化运营范本,有益于促使同类场馆冲破传统管理的束缚,朝着数据引领的精细经营方向转变,从而改善整体的服务品质。商城和订单模块的整合给场馆拓展衍生收益赋予了数字化途径,具有向其它运动类型的场馆复制推广的示范意义。
1.2 国内外研究现状
1.2.1 国内现状
国内对于预约管理以及场馆运营信息化方面的研究开始得比较早,早期的系统大多采用单机或者局域网的形式部署,功能主要为基本的预约记录。伴随着Web技术的发展,基于B/S架构的预约系统逐渐成为主流,系统功能也从最初的单个时段占用记录扩展到了用户管理、权限控制、数据统计等各个方面。近些年来,前后端分离架构被广泛使用,使得系统开发效率和可维护性得到了提高,各类场馆管理系统的功能完整性和交互体验都有了很大的改善。
2026年,陈锟设计并开发出一款基于微信小程序的轻量化高校机房预约系统,该系统前端用微信小程序实现了可视化的预约界面和实时状态查询,后端用Node.js、Express框架,可以支持时段预约、预约记录查询等功能,其资源实时状态展示机制给本系统场地占用状态动态更新的设计提供直接借鉴。陆向艳、刘峻在2025年开发出基于SpringBoot的机房预约系统,系统采用B/S结构和MySQL数据库,包含用户管理、机房预约管理、系统管理三个模块,技术选型与本系统高度一致,预约流程设计思路可以为本系统预约审核机制的建立提供一定的借鉴[5]。李超胜等在2025年设计了一个基于微信小程序和蓝牙技术的图书馆座位预约管理系统,可以实现提前预约、现场签到、暂离保留等功能,灵活的座位状态管理逻辑给本系统场地时段状态切换的设计提供了一些思路[6]。2025年陈建文提出基于Python技术的高校公共计算机实训室预约系统,学生可以在线查询空闲情况并进行预约,管理员可以在线审核和查看使用情况,其在线审核与利用率统计的设计思想给本系统管理员审核流程的细化提供了一定的启示[7]。李明炀、白一凡在2025年使用SpringBoot和Vue3作为技术核心开发了基于AI的火车票订票系统,采用前后端分离的方式进行开发,其订单管理以及用户数据关联的设计思路为本系统商城订单模块的数据结构设计提供了一定的借鉴[8]。
从以上国内的研究成果来看,现有的预约类系统对于基础流程的管理比较完善,但是大多数系统功能比较单一,很少将预约管理、商城销售、会员体系、使用登记等整合到一个平台上形成闭环。本系统在功能设计上对已有研究进行了拓展,把场馆运营的各个业务线都纳入到一个管理视图当中,填补了目前系统缺少综合运营支持的不足。
1.2.2 国外现状
国外对于预约系统的研究起步比国内早很多,研究视角更多地集中于以用户为中心的系统设计方法论,重视在需求分析阶段充分考虑用户的意见,用量化工具来检验系统的可用性。就技术路线而言,国外对于实时数据驱动、动态资源调度、机器学习辅助决策等方面的研究比国内要更加深入,系统架构大多采用微服务化或者服务解耦的设计方式。
Nadiansyah在2025年利用以用户为中心的设计方法,创建了一个包含360度全景展示的婚礼套餐预约系统,用系统可用性量表对20名用户进行了评价,得到的SUS评分是80.7分,研究过程中有关用户认知负担和操作路径优化的分析方法可以为本系统的前端交互设计原则提供参考[9]。2025年张等提出基于患者中心实时动态资源分配策略的超声检查预约系统,开放了检查室属性、工作量调整、医嘱互斥规则等参数设置,实现了多渠道、多模式的预约服务,其动态资源配置策略给本系统场地时段管理灵活配置预约参数功能设计提供了参考[10]。Shao和Liu在2024年用SpringBoot和MyBatis搭建了一个在线点餐系统,包括账户管理、功能模块、数据库设计等全部内容,系统整体架构设计方式与本系统技术路线相似,商品管理以及订单流转的实现逻辑对本系统商城和订单模块的设计有着直接的参考意义[11]。2024年Silva等提出了一种基于机器学习的弹性卡车预约系统概念模型,利用实时数据流识别干扰事件并动态调整预约计划,其系统异常处理和调度重排的思路给本系统取消预约和审核流程的健壮性设计提供了一些参考[12]。2022年Yang以SpringCloud微服务架构为基础设计出在线点餐系统,前端使用Vue.js,后端提供账户、菜单、订单、用户四个独立的服务,前后端分离的架构模式以及服务拆分的思想给本系统整体架构的设计提供了借鉴[13]。
国外研究在动态资源调度、用户中心设计方法和量化可用性评价等方面有丰富的经验,但是大部分研究场景比较垂直,缺少对综合性运营管理系统多模块协同的整体设计研究。本系统在吸收国外研究思想的基础上,根据羽毛球场馆实际业务特点,把预约调度、商城经营、会员管理等各方面融合到一个平台上,形成了适合本土应用的完整解决方案。
1.3 主要研究内容
本文的主要工作就是设计并实现一个符合羽毛球场馆实际运营需要的综合管理系统,使用Vue和SpringBoot作为前后端主要的开发框架,用MySQL数据库来存储数据。研究工作从需求分析阶段开始,对场馆运营流程进行梳理,确定管理员和普通用户两个角色在场地预约、使用登记、商城购物、会员管理等业务场景下具体的功能需求,得出系统的功能需求规格。在架构设计阶段确定前后端分离的技术路线,划分出用户界面层、应用服务层、数据持久层的职责边界,对场馆信息、预约记录、订单、商品等核心业务实体进行概念建模和逻辑设计,得到完整的数据库结构方案。模块实现阶段按照场地信息管理、场地时段管理、场馆预约管理、使用登记管理、在线商城、订单管理、会员购买、新闻资讯等各个功能模块的后端接口开发和前端页面实现。本文研究的重点是业务流程的完整性、各个模块之间的协作能力,并没有涉及到高并发场景下性能优化以及分布式部署方案。研究预期成果为一个可以运行的系统原型,包含完整的功能模块实现、数据库设计文档和基于典型用例的测试验证报告,整个研究方法按照需求分析、架构设计、编码实现、功能测试的工作流程进行,为后面各个章节的详细展开提供框架基础。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是由Pivotal团队在Spring框架的基础上开发出的快速开发框架,它的主要思想就是约定优于配置。传统的Spring项目需要开发者自己编写大量的XML配置文件,并且一一协调各个组件之间的依赖关系,而Spring Boot用自动配置的方式把这许多事情交给框架去做,使开发者可以专心于业务逻辑的实现,大大缩短了项目初始化以及环境搭建的时间[14]。
框架自带了Tomcat、Jetty等Web容器,应用程序可以以可执行JAR包的形式独立运行,不需要依赖外部服务器的安装和配置。在依赖管理层面,Spring Boot通过Starter机制将功能相关的依赖库打包为统一的引入单元,开发者引入spring-boot-starter-web即可获得完整的Web开发能力,引入spring-boot-starter-data-jpa则自动获得数据访问层的配置支持。本系统后端使用的是Spring Boot,接口层用注解驱动的方式定义路由规则,业务逻辑层的组件通过依赖注入的方式解耦,使得场馆预约、订单管理、会员体系等各个业务模块的服务互相独立、互不影响。Spring Boot对于RESTful接口风格的原生支持,也给系统前后端之间数据交互提供了一个明确的接口规范。
2.2 Vue前端框架
Vue.js是尤雨溪于2014年发布的渐进式JavaScript框架,用以构建用户界面。与传统的页面渲染方式不同的是,Vue使用的是基于虚拟DOM的响应式数据绑定机制,当组件内部的数据状态发生变化的时候,框架会计算出最小化的DOM更新方案并应用到实际页面上,从而避免了全量重绘造成的性能开销[15]。组件化是vue前端开发的主要组织形式,把模板、脚本、样式封装成独立的单文件单元,组件间用属性传递和事件通信实现数据流转,从而达到页面结构的复用性和可维护性的提高。
本系统前端采用Vue框架开发,场地信息展示、预约表单提交、订单状态查询、商城商品浏览等界面都是用独立的组件来完成的。Vue Router是Vue应用的路由组件,不同的角色功能入口由路由守卫控制权限进入,管理员后台和普通用户的界面上线程隔离。Axios是HTTP客户端库,它负责前端和后端的数据通信工作,异步请求的发起以及响应结果的接收都在组件生命周期的钩子函数里完成,从而使得页面的数据和后端的状态保持一致。秦冬认为Vue框架在前端开发中采用组件复用和响应式数据绑定的方式可以提高开发效率、界面的一致性,这与本文系统开发实践一致[15]。
2.3 MySQL数据库
MySQL是目前被广泛使用的、使用最多的开源关系型数据库管理系统之一,它的维护工作是由Oracle公司来完成,并且会不断的进行升级。底层使用的存储引擎为InnoDB,默认值为InnoDB,InnoDB支持事务处理、行级锁定、外键约束,在多用户并发操作的时候可以保证数据的一致性、完整性[16]。MySQL的SQL标准兼容性好,可以做复杂的多表关联查询、子查询、聚合函数等操作,给业务数据的灵活检索提供充足的查询能力。
本系统所有的业务数据都存入MySQL数据库,数据库结构包含用户账户、场馆信息、预约记录、使用登记、订单、商品、会员等级等主要的业务表,表和表之间用外键联系起来形成业务实体之间的逻辑关系。Spring Boot使用MyBatis框架以及MySQL来创建数据访问通道,Mapper层的SQL语句存放在XML文件里,业务层采用接口调用的方式来执行数据的增删改查操作,数据访问层和业务逻辑层划分清楚,有利于后期的维护和功能的拓展。数据库连接池使用HikariCP,保证系统在运行过程中保持稳定的连接复用,减小频繁创建销毁连接所造成的资源消耗。
2.4 前后端分离架构
前后端分离架构就是把用户界面呈现和服务端业务处理分开成两个工程单元的系统组织方式。在这种架构模式之下,前端工程主要完成页面的渲染以及用户的交互逻辑工作,而后端工程则担当起业务规则的执行和数据的保存任务,两者之间借助标准的HTTP接口来达成数据的交流,各自的技术选型,开发速度以及部署方法均保持着相互分离的状态[17]。相比于传统的服务端模板渲染方式,前后端分离架构使得前后端团队可以同时进行各自的工作,接口契约一旦确定,就可以独立开发和测试,开发协作效率大大提高。
本系统严格遵循前后端分离的架构原则,Vue前端项目独立构建,采用静态资源的形式进行部署,所有的页面数据来源都是通过调用后端RESTful接口来获取的,后端Spring Boot服务以JSON格式返回响应数据,不承担任何页面渲染的工作。后端接口按照业务领域进行分组,场馆预约、商城商品、订单管理、会员等级等各个业务域的接口路径清晰分离,前端在不同的功能页面中根据需要调用相应的接口来完成数据交互。该架构设计使得系统具有较好的扩展性,将来接入移动端或者小程序的时候,后端接口不需要做任何修改就可以直接使用。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
本系统所使用的SpringBoot、Vue都是目前JavaWeb开发中使用最广的两大主流框架,开发文档齐全,社区活跃,相关技术资料充足。后端用SpringBoot创建RESTful服务,前端用Vue创建响应式的界面,数据持久化层使用MySQL关系型数据库,三者的技术定位各有所长,分别负责服务处理、界面交互和数据存储的工作,组合使用时互相兼容、配合稳定。前后端分离架构在同类型的Web系统里有着许多成熟的技术实践,系统的整体结构比较合理,技术路线清楚,没有遇到过技术上的难题或者未知的风险。从开发环境来讲,IntelliJ IDEA、Node.js、Maven等常用开发工具可以很好地支持本项目构建和调试的需求,技术上具备了充分的可行性。
3.1.2 操作可行性
系统前端使用Vue框架进行开发,页面布局符合常见的Web应用交互习惯,功能入口分块清晰,操作步骤简单直接。管理员端后台管理界面用左侧导航加右侧内容区的标准布局,各个功能模块之间的切换路径清楚,不需要记住复杂的操作顺序。普通用户的预约过程按照时间线的顺序来引导用户选择场地、选定时段并进行订单提交,每一个步骤都会立即给用户呈现页面上的反应信息,使用户理解较为简单。系统面向的用户主要是有一定网络使用基础的成年人,日常操作的复杂程度和主流电商、预约类应用相当,学习成本在可接受范围内,操作可行性有保证。
3.1.3 经济可行性
本系统开发过程中使用到的开源框架和免费开发工具有SpringBoot、Vue、MySQL等,这些开源框架和工具都是采用开源授权的方式提供的,不需要支付商业许可费用。开发阶段所必需的软硬件资源主要依靠本地开发机,运行阶段可以部署在普通服务器或者云服务基础实例上,租用成本处于可控范围内。系统投入运行之后,运维工作主要是针对数据库定时备份和功能更新的处理,日常维护成本低。相比于传统的人工管理模式,本系统的开发一次性投入可以快速提高场馆运营效率,从而收回开发成本,在较小的预算下完成信息化改造,具有较好的经济合理性。
3.2 功能需求分析
3.2.1 管理员角色功能需求
管理员属于系统后台的关键操作人员,其主要工作就是对场馆运营的全部环节数据实施管控并加以保养。管理员可以对场地基本信息进行增删改查,设置各个场地的可用时间段,审核用户的预约申请,查看使用登记记录并进行核销或者备注操作。商城板块商品上架、下架、库存调整都是管理员来操作的,订单状态的流转处理也都在管理员的权限之内。管理员可查阅取消预约记录、结束使用记录,了解场地全部的使用情况,对运营数据展开综合的管理。
图3-1管理员用例图
3.2.2 用户角色功能需求
普通用户是系统前台的主要使用者,注册登录之后可以访问场馆的相关服务。用户可以浏览场馆基本信息,查看各个场地可预约时段,提交预约申请,跟踪审核状态,完成使用登记。会员购买功能可以供用户选择会员等级并完成支付,购买之后会得到相应的折扣优惠。在线商城可以供用户浏览商品、加入购物车、提交订单。新闻资讯模块给用户带来场馆公告、活动信息的浏览服务,用户可以查看详细的内容。
图3-2用户用例图
3.3 非功能需求分析
3.3.1 可用性
系统前端界面要具有明显的功能区划分,用户登录之后不需要再做任何引导就可以找到场地预约、使用登记、在线商城等主要的操作入口。页面布局采用自上而下的信息展示顺序,预约流程按照场地选择、时段确认、订单提交的时间线逐步推进,每一个步骤的操作都会得到系统的提示。管理员后台用到了左侧导航栏加右侧内容区的方式,实现了前后端各个模块的转换。系统整体响应时间在常规网络环境下处于可以接受的范围之内,用户提交表单或者刷新列表之后,数据更新的结果会在很短的时间内出现在当前页面上。
3.3.2 可靠性
系统对于预约申请、订单提交这些重要的业务操作,应该保证数据状态的变动同数据库持久化成果达成绝对一致。用户提交预约申请之后,系统立刻把记录存入数据库,管理员审核操作引起状态更新的时候,也会一同对相关的预约记录字段加以修改。使用登记模块在用户完成支付之后产生登记记录,登记记录同预约订单的关联字段一一对应,任何环节的操作失败都不会造成部分数据残留。系统对于重复的同一个时间段的预约申请进行拦截,防止由于网络延迟或者快速点击导致的重复记录。取消预约操作完成之后,该时段立刻被释放并且可以被其他用户使用。
3.3.3 安全性
系统对未登录用户的访问请求做统一拦截,所有需要身份认证的页面或者接口都会跳转到登录页面。用户登录时,前端将密码加密后发送给后端,后端在验证时不会保存明文密码。普通用户和管理员的权限边界在接口层进行严格的划分,普通用户不能调用管理员专用接口对场地信息进行修改或者对订单状态进行变更。用户提交的预约申请、订单信息只允许本人或者管理员查看,其他用户不能查看。系统对每一次登录的操作时间、登录IP地址都进行记录,用户可以到个人中心查看最近的登录记录,发现有异常的时候可以直接修改密码。
3.3.4 可维护性
系统代码采用分层结构,前端组件按功能模块分别放在不同的目录里,后端控制器、服务层、数据访问层分别对应着独立的Java包结构。场地预约、商城订单、会员管理等业务逻辑分别封装成独立的服务类,修改某一个模块的功能不会影响到其它模块的正常工作。数据库表结构的变更用版本化的SQL脚本来管理,新增字段或者修改索引的操作可以追踪到执行记录。系统运行时产生的日志文件按时间戳进行滚动保存,管理员可以查阅日志来找出操作出现异常的上下文信息。
3.3.5 兼容性
系统前端界面在主流浏览器的近期版本上应该具有相同的渲染效果和交互行为,即Chrome、Firefox、Edge浏览器。页面布局使用相对单位来实现尺寸适配,在不同的分辨率显示器上都不会出现横向滚动条或者关键按钮被遮挡的情况。表单输入框以及按钮的点击区域大小合适,对于触摸屏设备来说也具有可操作性。后端服务运行在标准的Java运行时环境中,不需要使用到任何操作系统特有的特性,在Windows和Linux下都可以正常启动并且提供服务。
第四章 系统设计
4.1 系统架构设计
本系统采用前后端分离的分层架构模式进行整体构建。用户界面层由Vue框架驱动,负责页面渲染、路由管理与用户交互响应,通过Axios与后端进行HTTP通信。应用服务层以SpringBoot为核心,按业务领域划分控制层、服务层与数据访问层,各层职责边界清晰,服务之间通过依赖注入完成协作。数据持久层采用MySQL数据库存储全部业务数据,MyBatis框架作为ORM中间件负责SQL执行与结果映射。系统支持层涵盖基础运行环境与公共工具组件,包括JDK运行时、Maven依赖管理、JWT令牌校验等基础能力支撑模块。各层之间通过标准接口完成数据流转,整体结构具备良好的可维护性与横向扩展潜力。系统架构图如图4-1所示。
图4-1系统架构图
4.2 系统功能结构设计
本系统围绕羽毛球场馆日常运营的核心业务构建功能体系,设置管理员与普通用户两类操作角色。管理员端覆盖场地信息管理、场地时段管理、场馆预约管理、使用登记管理、商城管理、订单管理六个功能模块,支持对场馆运营全链路数据的增删改查与状态流转处理。普通用户端涵盖场地预约、场馆信息、使用登记、购买会员、新闻资讯、在线商城六个功能模块,覆盖用户从浏览场馆到完成预约、从商品浏览到订单提交的完整服务流程。两类角色的功能模块在数据层面通过统一的数据库结构进行关联,预约记录、订单信息、使用登记等核心业务数据在管理员端与用户端之间保持实时一致。该系统功能结构如图4-2所示。
图4-2系统功能结构图
4.3 系统流程设计
4.3.1 场地预约流程设计
用户发起场地预约请求后,系统对其登录状态与预约资格进行验证,通过验证后进入场地选择与时段确认环节,提交预约申请后由管理员进行审核,审核通过则预约成功,审核未通过则返回用户并提示原因。场地预约流程图如图4-3所示。
图4-3场地预约流程图
4.3.2 使用登记流程设计
用户到达场馆后发起使用登记操作,系统核验预约订单的有效性,订单有效则引导用户完成支付操作,支付成功后生成登记记录并更新场地使用状态,管理员可在后台查看并核销登记记录。使用登记流程图如图4-4所示。
图4-4使用登记流程图
4.4 数据库设计
4.4.1 概念模型设计
设计本系统的概念模型,关键在于理清场馆信息、预约记录、使用登记、用户账户、订单与商品这几个核心业务实体之间错综交织的关联关系。从业务视角来看,一个场馆信息实体对应多个预约时段配置,一条预约记录关联着特定用户与特定场馆的一次时段占用行为,而使用登记则是预约行为在现实层面的完成凭证,三者之间构成了一条从资源配置到业务消费的纵向链路。商品与订单之间存在典型的一对多关系,同一商品可被多个用户分别购买形成独立订单,订单实体同时关联买家用户与商品信息,承载了商城交易行为的核心数据。会员等级实体通过用户账户中的等级字段与用户建立关联,会员折扣在订单结算时被引用,体现为订单数据中的价格修正属性。概念模型以实体-联系图作为可视化表达工具,将现实世界中的业务对象抽象为具有属性集合的实体,并以一对一、一对多、多对多等联系语义描述实体间的相互作用关系[18]。基于以上分析,系统全域数据结构的E-R图为后续逻辑模型设计提供了结构依据。全局E-R模型如图4.4所示。
图4-4全局ER图
4.4.2 数据库逻辑设计
数据库逻辑设计阶段的核心任务是将概念模型中的实体与联系映射为关系数据库中的具体表结构,在保证业务逻辑完整性的前提下兼顾查询效率与数据冗余的平衡。本系统以第三范式为基本准则对各数据表进行设计,确保每张表的非主键字段直接依赖主键而非存在传递依赖,从结构层面规避数据异常风险[19]。实体之间的关联关系通过外键字段在子表中维护,一对多关系在多端表中保存主表主键作为外键引用,多对多关系通过中间关联表进行分解。各业务表的主键均采用自增整型字段,时间戳类字段统一记录创建时间与更新时间,便于数据追溯与变更审计。逻辑设计完成后形成完整的数据库表结构说明,包括字段定义、数据类型、长度约束与字段含义,为后续编码实现阶段的数据访问层开发提供依据。
(1)用户账户表主要是用来存储系统所有用户的账户基本信息。主要包括用户ID、账户状态、用户名、密码等字段。如表4-1所示。
表4-1用户账户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | user_id | int | 11 | 主键 |
| 2 | state | smallint | 11 | 账户状态 |
| 3 | user_group | varchar | 32 | 所在用户组 |
| 4 | login_time | timestamp | - | 上次登录时间 |
| 5 | phone | varchar | 20 | 手机号码 |
| 6 | username | varchar | 50 | 用户名 |
| 7 | nickname | varchar | 50 | 昵称 |
| 8 | password | varchar | 64 | 密码 |
| 9 | avatar | varchar | 200 | 头像地址 |
| 10 | create_time | timestamp | - | 创建时间 |
| 11 | vip_level | varchar | 100 | 会员等级 |
| 12 | vip_discount | double | - | 会员折扣 |
(2)普通用户表主要是用来存储普通用户的扩展信息与审核状态。主要包括普通用户ID、用户姓名、手机号码、审核状态等字段。如表4-2所示。
表4-2普通用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | ordinary_user_id | int | 11 | 主键 |
| 2 | user_name | varchar | 100 | 用户姓名 |
| 3 | mobile_phone_number | varchar | 20 | 手机号码 |
| 4 | examine_state | varchar | 16 | 审核状态 |
| 5 | is_vip | varchar | 100 | 可见会员 |
| 6 | user_id | int | 11 | 用户ID |
| 7 | create_time | datetime | - | 创建时间 |
| 8 | create_by | int | 11 | 创建用户ID |
| 9 | update_time | timestamp | - | 更新时间 |
(3)场馆信息表主要是用来存储各羽毛球场地的基本运营信息。主要包括场馆信息ID、场馆编号、场馆名称、场馆价格等字段。如表4-3所示。
表4-3场馆信息表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | venue_information_id | int | 11 | 主键 |
| 2 | venue_no | varchar | 64 | 场馆编号 |
| 3 | venue_name | varchar | 100 | 场馆名称 |
| 4 | cover_chart | varchar | 200 | 封面图 |
| 5 | venue_address | varchar | 150 | 场馆地址 |
| 6 | venue_price | double | - | 场馆价格 |
| 7 | venue_introduction | varchar | 500 | 场馆介绍 |
| 8 | venue_status | varchar | 64 | 场地状态 |
| 9 | venue_reservation_limit_times | int | 11 | 预约限制次数 |
| 10 | create_time | datetime | - | 创建时间 |
| 11 | create_by | int | 11 | 创建用户ID |
| 12 | update_time | timestamp | - | 更新时间 |
第五章 系统实现
5.1 管理员角色功能实现
5.1.1 场地信息管理
场地信息管理模块主要是对羽毛球场地的基本运营资料进行维护与管控。管理员可在列表页面浏览全部场地的当前状态,通过表单操作完成新场地的录入,对已有场地的基本资料进行编辑修改,对停用或废弃场地执行删除操作。场地状态的切换操作同样在本模块内完成,管理员调整某一场地的开放状态后,前台用户端的场馆信息展示将同步更新,保持数据一致性。场地信息管理界面如图5-1所示。
图5-1场地信息管理界面
5.1.2 场地时段管理
场地时段管理模块主要是对各场地开放的可预约时段进行配置与调整。管理员可新增时段配置记录,指定时段名称与对应的时间区间,对已有时段进行修改或将其从可选列表中移除。用户端在提交预约申请时所看到的时段选项,直接来源于本模块中处于启用状态的时段配置记录。当节假日或特殊活动需要调整开放时段时,管理员在本模块完成配置变更后即时生效,无需重启系统或手动通知用户。场地时段管理界面如图5-2所示。
图5-2场地时段管理界面
5.1.3 场馆预约管理
场馆预约管理模块主要是对用户提交的场地预约申请进行审核与状态跟踪。管理员进入模块后可查看全部待审核、已审核、已取消的预约记录列表,对处于待审核状态的申请执行通过或拒绝操作,并可在审核时填写回复内容反馈给用户。已通过的预约记录与使用登记模块形成关联,已拒绝或已取消的记录保留完整历史供查阅。管理员还可按场地编号、预约日期等条件对预约记录进行筛选,快速定位目标记录。场馆预约管理界面如图5-3所示。
图5-3场馆预约管理界面
5.1.4 使用登记管理
使用登记管理模块主要是对用户实际到场使用场地的登记记录进行查看与核销处理。管理员可浏览全部使用登记记录,查看每条记录对应的场地信息、用户信息、支付状态及支付金额,对已完成使用的记录执行核销标记操作,在备注字段中补充必要的场地使用说明。支付状态的核实工作在本模块内完成,管理员确认支付信息无误后更新对应记录的状态字段。使用登记管理界面如图5-4所示。
图5-4使用登记管理界面
5.1.5 商城管理
商城管理模块主要是对在线商城中展示的商品信息进行全生命周期的管理操作。管理员可录入新商品,填写商品标题、描述、价格、库存及分类信息,上传封面图与多张主图;对已上架商品进行编辑修改,调整价格或库存数量;对滞销或下架商品执行状态切换操作。商品的上架状态决定了用户端是否能够浏览该商品,管理员可灵活控制各商品在商城中的可见性。商城管理界面如图5-5所示。
图5-5商城管理界面
5.1.6 订单管理
订单管理模块主要是对商城交易产生的用户订单进行状态流转处理与记录查阅。管理员可按订单状态筛选待发货、已发货、已完成等不同状态的订单列表,对待发货订单填写物流信息并执行发货操作,订单状态随之更新为已配送。对于用户提交的退款申请,管理员在本模块内完成审核,选择通过或拒绝,并填写处理说明回复用户。历史订单记录支持按时间区间与关键字段进行检索。订单管理界面如图5-6所示。
图5-6订单管理界面
第六章 系统测试
6.1 测试目的
软件测试是系统上线前质量把控的关键环节。本系统的测试目的在于从全链路数据一致性的角度出发,验证各功能模块在完整业务流程中的数据流转是否准确无误,重点检验预约申请、使用登记、订单生成等核心业务操作在跨模块协同时的数据状态是否保持一致[20]。与此同时,测试工作还涵盖对系统边界条件的容错校验,包括输入字段为空、数值超出合法范围、重复提交等异常操作场景下系统的响应处理是否符合预期规格。通过系统性的测试覆盖,排查潜在的逻辑缺陷,为系统的稳定投入使用提供质量基础。
6.2 测试方法
本系统采用黑盒测试作为主要的功能验证手段。黑盒测试聚焦于系统的外部行为表现,测试人员依据功能规格说明书构造测试输入,观察系统的实际输出是否与预期结果吻合,不涉及内部代码逻辑的检查。测试用例的设计依据等价类划分原则,对合法输入、非法输入与边界值分别构造对应用例,保证测试覆盖面的完整性。
具体测试过程中,每个功能模块按照操作步骤逐项执行,记录实际系统响应,并与预定的预期结果进行比对。测试环境与生产环境在技术栈配置上保持一致,测试数据独立维护,避免干扰正式数据,测试结论依据实际运行结果客观记录。
6.3 测试内容
(1)场地预约功能测试如表6-1所示。
表6-1场地预约功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常预约流程 | 登录后选择场地与时段,提交预约申请 | 预约申请成功提交,进入待审核状态 | 符合预期 |
| 未登录状态发起预约 | 未登录情况下访问预约页面 | 系统跳转至登录页面 | 符合预期 |
| 选择已占用时段 | 选择已有预约的场地时段提交 | 系统提示时段不可用,申请未提交 | 符合预期 |
| 取消待审核预约 | 在历史预约记录中对待审核申请发起取消 | 预约记录状态更新为已取消 | 符合预期 |
(2)使用登记功能测试如表6-2所示。
表6-2使用登记功能测试表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 有效预约完成登记 | 选择已审核通过的预约记录发起登记并支付 | 登记记录成功生成,支付状态更新 | 符合预期 |
| 无效预约发起登记 | 使用已取消预约发起登记操作 | 系统提示订单无效,登记未生成 | 符合预期 |
| 管理员核销登记 | 管理员在后台对已登记记录执行核销操作 | 记录状态更新为已核销 | 符合预期 |
测试结论
系统测试工作包含场地预约、使用登记、在线商城购物、会员购买、订单管理这五个主要的功能模块。场地预约功能测试,正常预约流程提交之后申请成功进入待审核状态,未登录状态下访问预约页面会跳转到登录页面,选择已占用时段系统提示不可用,取消待审核申请之后记录状态更新为已取消。使用登记功能测试,预约完成登记后记录产生、支付状态更新,无效预约发起登记系统提示订单无效,管理员后台核销操作把记录状态更新为已核销。在线商城购物功能测试结果表明,正常提交商品订单之后,订单会被生成并入库,库存减少,库存为0时购买系统会提示库存不足,购物车里添加的商品数量不变,修改之后订单数量不变,查看历史订单时可以获取到订单记录,并且状态为待发货。在会员购买功能测试中,会员成功购买会员后,用户的账户会同步更新为会员等级,并且生效,当支付失败时,系统会给出失败提示并且会员等级不会发生改变,查看会员权益时各个等级的名称、价格以及权益都会显示完整。订单管理功能测试中,管理员发货操作把订单状态改为已发货,审核退款申请通过之后订单状态变为已退款,审核退款申请拒绝之后订单状态变为已拒绝并发送用户反馈,订单条件筛选之后列表只显示符合条件的记录。所有的测试用例实际结果都达到了预期的效果,系统的功能运行正常。
总结
羽毛球运动的大众化发展给场馆运营管理工作提出更高的要求,传统的依靠人工协调的管理方式已经不能满足各种各样的业务需求了。本文就以上问题设计并开发出一个基于Vue和SpringBoot技术的羽毛球场馆运营管理系统,包含场地预约、使用登记、商城购物、会员管理等各个方面,实现了系统的各项主要功能。
系统实现过程按照需求分析、架构设计、编码实现、功能测试的标准流程依次进行。需求分析阶段确定了管理员和用户两个角色的功能界限,架构设计阶段确定了前后端分离的技术路线,采用SpringBoot实现后端服务,Vue实现前端交互界面,MySQL实现数据持久化;编码阶段按照场地信息、时段设置、预约审核、使用登记、商城商品、订单管理、会员体系等模块逐个完成接口开发和页面实现;测试阶段用黑盒测试对核心业务流程做了系统的检验,所有的测试用例都达到了预期的结果。
未来系统迭代的方向可以先加入真实的支付接口来完善交易闭环,创建运营数据看板给管理决策提供数据支持,采用消息推送的方式提高预约状态变化时用户的触达及时性。从更长远的角度来说,该系统所具有的功能框架具有向其他类型的体育场馆迁移复用的潜力,在全民健身政策不断推进的大背景下,场馆信息化管理的需求量还会越来越大,系统有较好的发展前景。
参考文献
[1] 陈锟.基于微信的轻量化高校机房预约系统设计与实现[J].软件, 2026, 47(01): 99-101.
[2] 郭琳琳,李同济,崔英.儿童医院全景预约系统设计及应用实践[J].医学信息学杂志, 2025, 46(07): 85-90.
[3] 李明炀,白一凡.基于AI的火车票订票系统设计与实现[J].电脑编程技巧与维护, 2025, (04): 141-144.
[4] 陈锟.基于微信的轻量化高校机房预约系统设计与实现[J].软件, 2026, 47(01): 99-101.
[5] 陆向艳,刘峻.基于SpringBoot的机房预约系统的设计与实现[J].工业控制计算机, 2025, 38(07): 128-129.
[6] 李超胜,曹姝萍,郝继升.图书馆预约小程序设计与实现[J].信息与电脑, 2025, 37(11): 121-123.
[7] 陈建文.基于Python的高校公共计算机实训室预约系统设计[J].现代信息科技, 2025, 9(09): 84-87+95.
[8] 李明炀,白一凡.基于AI的火车票订票系统设计与实现[J].电脑编程技巧与维护, 2025, (04): 141-144.
[9] Nadiansyah A, Hakim A S, Siagian M A H A, et al. Design and implementation of a 360-degree panoramic wedding package booking system using user-centered-design[J]. International Journal of Information Technology, 2025, 18(1): 1-7.
[10] Zhang Y, Luo Y, Qiu L, et al. Design of an ultrasound appointment system based on a patient-centered real-time dynamic resource allocation strategy[J]. Frontiers in Public Health, 2025, 13: 1496860.
[11] Shao W, Liu K. Design and Implementation of Online Ordering System Based on SpringBoot[J]. Journal of Big Data and Computing, 2024, 2(3): 23-29.
[12] Silva D F R M, Frazzon M E, Silva D M V. Design of flexible truck appointment system based on machine learning approach[J]. International Journal of Logistics Systems and Management, 2024, 48(2): 244-266.
[13] Yang Y. Design and Implementation of Online Food Ordering System Based on Springcloud[J]. Information Systems and Economics, 2022, 3(4): 51-57.
[14] 闾枫. Spring Boot项目开发教程[M].北京:人民邮电出版社, 2022: 264.
[15] 秦冬.浅析Vue框架在前端开发中的应用[J].信息与电脑(理论版), 2024, 36(13): 61-63.
[16] 郑晓霞,张艳艳,刘超. MySQL数据库原理及应用[M].北京:人民邮电出版社, 2024: 302.
[17] 柳伟卫. Vue.js+Spring Boot全栈开发实战[M].北京:人民邮电出版社, 2023: 484.
[18] 曾辉.关系数据库技术在计算机网络设计中的应用[J].信息与电脑(理论版), 2023, 35(14): 206-208.
[19] 胡劲.数据库信息管理系统的逻辑架构与功能设计探析[J].电脑知识与技术, 2023, 19(19): 96-98.
[20] 代晓倩,丁翠玲,高赛军.基于需求和源代码分析的软件回归测试技术[J].工业控制计算机, 2026, 39(1): 45-46.
致谢
毕业论文的完成,是四年本科学习生涯的句点,也是数月来埋头于设计文档、调试接口、反复修改的那段时光最具体的证明。该系统从最初的清单出发,经过反复推倒重来,最终才能完成全部的功能。写完这段致谢之后,心里更多的是一种踏实感,而不是一般意义上所说的感谢和感慨。
导师对本文的写作过程一直给予指导,在需求分析思路和数据库逻辑设计方面也提出了具体的修改意见,使论文论述更加清晰。就研究方向而言,导师的几次谈话使我对于系统边界是否保留或者去掉有了更加清晰的认识,而我课堂上学不到的宏观视角思考方式就是其中之一。
学习这件事,大部分时候是由一个人坐在屏幕前完成的,但是实验室的同学在关键节点上给予了各种各样的帮助,有人帮我排查了一个困扰了两天的跨域问题,有人在深夜帮我看了测试用例的逻辑漏洞。这些零散的、不是刻意而为的帮助,最后都变成了论文里某个细节得以完善的理由。
家人对于这件事的态度一直都是支持的,从不追问进度,也不施加压力,这样的不打扰就是一种重要的支持方式。选择了该专业、选择了该研究方向,最终走到论文答辩这一步,背后有很多本不在计划之内的变化。能够把一件事情从开始做到结束,本身就是一种收获。
点赞+收藏+关注→私信领取本源代码、数据库