期末做的javaweb的课设作业,源码已上传
一、 引言
本项目是一个基于Spring + Spring MVC + MyBatis的志愿者管理系统,使用Maven进行包管理,旨在为大学生志愿者活动提供一个高效、便捷的管理平台。系统能够帮助志愿者管理活动报名、个人信息修改、密码管理等功能,同时也能帮助活动举办方发布活动、编辑活动信息,提升管理效率和便捷度。主要功能包括志愿者信息管理、活动信息管理、报名管理、查询与统计等功能。
二、 需求分析
1. 活动信息管理:
添加活动:举办方能添加新的活动信息,包括活动名称、举办方、地点、活动名额、已报名人数等基本信息。
编辑活动:举办方可以根据需要修改已存在的活动信息。
删除活动:举办方可以删除已经结束或者不再进行的活动。
查询活动:提供根据活动名称进行查询的功能,支持模糊查询。
查看所有活动:举办方可以查看系统中所有的活动信息,并进行管理。
2. 志愿者信息管理:
注册新志愿者:志愿者需通过举办方账号进行系统注册,系统将自动生成志愿者ID并记录志愿者的基本信息。
编辑志愿者信息:举办方可编辑志愿者的基本信息。
删除志愿者信息:举办方可以删除无效的志愿者信息。
查询志愿者信息:举办方可以查询特定志愿者的基本信息。
查看所有志愿者:举办方可以查看系统中所有注册的志愿者信息。
3. 报名管理:
报名活动:志愿者可以通过系统报名参加活动,系统会记录报名日期、志愿者信息和活动信息。
取消报名:志愿者可以取消自己已经报名的活动,系统会更新活动的报名人数和志愿者的报名状态。
查看报名记录:志愿者只能查看自己和志愿者的活动报名记录,管理员可以查看所有志愿者的活动报名记录。
4. 权限控制:
系统通过权限控制对不同角色(如举办方、志愿者)进行不同的操作权限设置,确保系统的安全性。

三、 系统设计
3.1 总体设计
1. 数据存储的实现细节
在本志愿活动管理系统中,数据存储部分采用了MyBatis框架与数据库进行交互,数据持久化通过JDBC实现,并通过XML文件配置MyBatis映射。具体存储实现如下:
1) 数据库设计:
系统使用MySQL数据库进行数据存储,数据库包含多个表格,主要包括:activity_info(活动表)、volunteer_info(志愿者信息表)、participate_list(报名记录表)、volunteer_card(志愿者账号表)、organizer_card(举办方账号表)等。表的字段设计如下:
activity_info表:
activityId (INT): 活动ID,主键,自增
activityName (VARCHAR): 活动名
activityOrganizer (VARCHAR): 举办方
address (VARCHAR): 地点
participantLimit (INT): 活动名额
registeredCount (INT):已报名人数
participate_list表:
serNum (INT): 报名记录ID,主键,自增
volunteerId (INT): 关联的用户ID
activityId (INT): 关联的活动ID
register_date (DATE): 报名日期
volunteer_card表:
volunteer_id (INT): 用户ID,主键,自增
username (VARCHAR): 用户名
password (VARCHAR): 密码
organizer_card表:
organizerId (INT): 举办方ID
username (VARCHAR): 用户名
password (VARCHAR): 密码
2) 数据库交互
通过MyBatis进行SQL映射,XML配置文件中定义了各类查询、插入、更新和删除操作,封装了数据操作的具体细节。例如,查询活动库存、报名记录,新增报名记录等。
采用Spring事务管理机制来保证操作的原子性,例如在报名书、还书操作时,确保库存减少和报名记录添加/更新是原子操作。如果某个环节出现异常,系统会回滚操作,避免数据不一致。
2. 主要代码文件及其实现功能
JSP页面:
login.jsp:登录页面,用户输入用户名和密码进行系统登录。
volunteer_index和organizer_index.jsp: 系统首页,介绍本志愿管理系统基本功能。
organizer_activities.jsp:举办方页面,展示所有活动信息,并提供删查功能。
organizer_activity_add.jsp: 举办方页面,提供活动添加功能。
organizer_activity_edit.jsp: 举办方页面,提供活动信息编辑功能。
organizer_volunteers.jsp: 举办方页面,展示所有志愿者信息,并提供删查功能。
organizer_volunteer_add.jsp: 举办方页面,提供志愿者添加功能。
organizer_volunteer_edit.jsp: 举办方页面,提供志愿者信息编辑功能。
organizer_ participate_list.jsp: 举办方页面,可查看活动的报名记录。
organizer_repasswd.jsp: 举办方页面,提供密码修改功能。
volunteer_activitys.jsp:志愿者页面,显示所有活动信息,允许用户进行报名和取消报名操作。
volunteer_info.jsp:志愿者页面,显示志愿者个人信息。
volunteer_info_edit.jsp:志愿者页面,提供志愿者个人信息修改功能。
volunteer_ participate_list.jsp:志愿者页面,可查看个人的活动报名记录。
volunteer_repasswd.jsp: 志愿者页面,提供密码修改功能。
Controller(Spring MVC控制器):
ActivityController.java:处理所有关于活动的请求,如查看所有活动、查询活动、增加、删除、编辑活动等。
LoginController.java:处理活动管理系统的用户(包括举办方和志愿者)登录、退出登录、密码修改等操作。
ReController.java:处理与活动报名相关的操作,如报名活动、取消报名活动、删除报名记录和活动管理。
Service层:
ActivityService.java:封装活动业务逻辑,调用对应的DAO进行数据持久化操作。
ReService.java:主要负责报名和取消报名活动的业务逻辑,通过调用数据访问层(ReDao)提供的方法实现数据操作。
VolunteerInfoService.java:主要用于处理与志愿者个人信息相关的业务逻辑,通过调用数据访问层(VolunteerInfoDao)的接口,与数据库进行交互,实现增删改、查等操作。
VolunteerCardService.java:负责处理与志愿者账号(VolunteerCard)相关的业务逻辑,包括志愿者账号的创建以及删除操作。该类通过调用数据访问层(VolunteerCardDao)提供的接口,完成数据的持久化操作。
LoginService.java:主要负责与用户(举办方和志愿者)相关的登录验证和密码管理功能,通过调用数据访问层(VolunteerCardDao和OrganizerDao)来执行验证和密码重置等操作。
DAO层(数据访问层):
ActivityDao 类负责与数据库交互,执行与活动(Activity)相关的增删改查等操作。该类使用了 MyBatis 框架的 SqlSessionTemplate 来执行 SQL 操作,并封装了访问数据库的具体实现,为业务层提供了操作数据库的接口。
ReDao 类负责与数据库交互,负责活动报名相关的增删改查等操作。该类使用 MyBatis 框架的 SqlSessionTemplate 来执行 SQL 操作,封装了与报名记录相关的所有数据库操作,并为业务层提供接口。
VolunteerInfoDao 类负责与数据库交互,进行与志愿者信息(VolunteerInfo)相关的增删改查等操作。该类使用 MyBatis 框架的 SqlSessionTemplate 来执行 SQL 操作,封装了所有与志愿者信息相关的数据库访问操作,并为业务层提供相关的接口。
VolunteerCardDao类负责与数据库交互,进行与志愿者账号(VolunteerCard)相关的增删改查等操作。该类使用 MyBatis 框架的 SqlSessionTemplate 来执行 SQL 操作,封装了所有与志愿者账号相关的数据库访问操作,并为业务层提供相关的接口。
OrganizerCardDao 类主要负责与数据库交互,处理与举办方信息(Organizer)相关的操作。该类使用了 MyBatis 框架的 SqlSessionTemplate 来执行 SQL 操作,封装了所有与举办方账户相关的数据库访问操作,为业务层提供接口。
Bean(实体类):
Organizer 类用于封装举办方的基本信息,包括举办方的 ID、用户名和密码。该类通过提供标准的 getter 和 setter 方法,确保数据的封装性与可访问性。
Activity 类封装了活动的基本信息(如 ID、名称、举办方、地点、活动名额、已报名人数等)。
Service 类负责封装活动报名记录的信息,通过 activityId、volunteerId、register_date 等属性来管理活动的报名信息。
ServiceDate 类是 Service类的扩展,专门用于处理日期字段的字符串格式。在 Service类中,日期字段是 Date 类型的,而在一些情况下,可能需要以字符串形式来展示日期,例如在前端页面显示或在某些报告中使用。通过增加registerDateStr,ServiceDate类能够更方便地处理这些字符串日期,而不必每次都手动转换。
VolunteerCard类封装了志愿者账户信息,包含了志愿者的基本信息,如志愿者ID、用户名和密码。
VolunteerInfo类表示活动馆管理系统中志愿者的详细信息,包含了志愿者的基本信息,如志愿者ID、姓名、地址、电话号码。
MyBatis文件:
organizerCard.xml定义了与 OrganizerCardDao 类相关的 SQL 映射,定义了与举办方账户管理相关的 SQL 查询、更新操作。
Activity.xml定义了与 ActivityDao类相关的 SQL 映射,包括插入、更新、查询、删除等操作。通过这些映射,ActivityDao 类可以与数据库进行交互,处理活动信息的增删改查操作
Re.xml是 ReDao的 MyBatis 映射文件,定义了与活动报名相关的数据库操作。主要功能包括:报名(在报名书时插入报名记录并减少活动名额、增加已报名人数)、取消报名(删除报名记录、增加活动名额、减少已报名人数)、查询报名记录(可以查看所有报名记录,或显示某个志愿者的报名记录)、删除指定报名记录)。
volunteerInfo.xml主要用于管理 volunteer_info 表中的志愿者信息,提供了基本的增查改删操作,包括:查询所有志愿者信息、根据 volunteer_id 查找志愿者信息、添加新志愿者、更新现有志愿者信息、删除指定志愿者、通过模糊查询姓名查找志愿者。
volunteerCard.xml主要用于管理 volunteer_card 表中的志愿者卡信息。提供了基于volunteer_id 进行查询、修改密码、插入新记录以及删除志愿者卡等操作。
CSS文件:
bootstrap.min.css、edit.css、header.css、index.css、info.css、info1.css用于页面样式的设置,包含表单、按钮、页面布局等的样式设计。
3.2 详细设计
1. 用户登录功能
用户需要输入用户名和密码来登录系统。

登录后进入用户主页

2. 报名功能
志愿者可以报名、取消报名活动,报名和取消报名时,系统会更新活动名额并输出提示信息。



报名功能主要包括以下业务逻辑:
检查库存:当用户请求报名时,首先需要检查该活动是否有名额,即 activity 表中该活动的 participantLimit是否大于 0。
更新名额:如果有名额,就减少该活动的名额数量,增加已报名人数。
记录报名:在报名表 participate_list 中插入一条新的记录,表示该志愿者报名了这个活动,并且记录报名时间。
返回报名结果:如果报名成功,则返回成功提示,如活动数量为0,页面则会显示已空,无法报名。

关键代码解析:
1) 报名/取消报名请求的前端界面
在用户点击报名/取消报名按钮后,前端会向后端发起报名请求,传递报名所需的参数(如活动ID和志愿者ID)。
<td><a href="returnactivity.html?activityId=<c:out value="${activity.activityId}"></c:out>">
<button type="button" class="btn btn-danger btn-xs">取消报名</button></a></td>
2) 控制器层(后端)
后端的 ReController 会接收到报名/取消报名请求,根据传入的 activityId 和 volunteerId 调用Servic层中的方法执行行报名/取消报名操作,利用RedirectAttributes来传递操作结果信息(成功或失败),并通过ModelAndView传递报名记录数据给视图层。
3) 服务层
ReService负责报名和取消报名活动的业务逻辑,它通过调用数据访问层(ReDao)提供的方法实现数据操作。下面是该类中每个方法的具体功能及其实现:
1. cancelActivity(long activityId, long volunteerId)
功能:处理活动取消报名的业务逻辑。
实现:
调用 ReDao.cancelActivityTwo(activityId) 来执行第一个取消报名操作(例如删除报名记录、更新活动状态等)。
调用 ReDao.cancelActivityOne(activityId, volunteerId) 来执行第二个取消报名操作(例如更新活动名额等)。
只有两个操作都成功(即返回值都大于 0)时,才认为活动取消报名成功,取消报名成功返回 true,否则返回 false。
2. registerActivity(long activityId, long volunteerId)
功能:处理活动报名的业务逻辑。
实现:
调用 ReDao.registerActivityTwo(activityId) 来执行第一个报名操作(例如在报名记录中插入新记录、设置报名日期等)。
调用 ReDao.registerActivityOne(activityId, volunteerId) 来执行第二个报名操作(例如更新活动已报名人数、减少活动名额等)。
只有两个操作都成功(即返回值都大于0)时,才认为活动报名成功,报名成功返回 true,否则返回 false。
4) DAO层(数据库操作):
registerActivityOne / cancelActivityOne:向 participate_list表插入报名记录,记录报名时间。
registerActivityTwo / cancelActivityTwo:更新 activity表中的活动名额。
3. 活动查询功能
志愿者和举办方可以根据活动名模糊查找活动,没有相关活动则会输出提示信息。


4. 活动添加和编辑功能
在前端页面中,举办方通过表单输入活动信息,包括活动名、举办方、地点、活动名额等,提交表单时,前端将用户输入的数据发送到后端。
控制器层接收前端提交的请求,提取请求参数,并将数据传递给服务层进行业务逻辑处理,根据服务层的返回结果,控制器决定跳转到成功或失败页面。


ActivityService 层负责活动的具体业务逻辑,处理查询、添加、编辑、删除等操作,通过 @Autowired 注解自动注入 ActivityDao,并使用其提供的方法进行数据库操作,返回值的判断(如返回的 int)用于判断操作是否成功,若返回值大于 0,表示操作成功。
ActivityDao 层与数据库交互,执行 SQL 操作。通过 SqlSessionTemplate 来执行查询、插入、更新和删除等操作,使用了 MyBatis 的命名空间和 SQL 映射,执行 SQL 语句时通过命名空间 + 方法名来查找相应的 SQL 语句,返回值类型是 int 或 List<Activity>,表示操作结果。
Activity.xml在 MyBatis 的 XML 配置文件中,使用 <insert>, <update>, <select>, <delete> 等标签来定义 SQL 语句,确保数据库操作正确执行。

具体页面:




5. 活动报名记录功能
根据志愿者ID,志愿者可查看自己的报名记录,如报名时间大于30天,则会在“备注”中显示“逾期”,志愿者在取消报名时已将报名活动的记录删除

举办方可查看所有志愿者活动的报名记录。

6. 志愿者信息的增删改查功能
交互流程:
Controller 层 通过 @RequestMapping 来监听前端请求。当用户发送请求(如添加志愿者、编辑志愿者、删除志愿者等)时,控制器会将请求传递给 Service 层 进行处理。
Service 层 负责接收请求,处理相关业务逻辑(如检查参数是否合法等),然后调用 DAO 层 来进行数据库操作。
DAO 层 使用 MyBatis 执行具体的 SQL 操作(查询、插入、更新、删除),并将结果返回给 Service 层。
Service 层 接收数据库操作的结果,根据操作成功与否返回true或false给Controller层。
Controller 层 将结果返回给前端,给用户相应的提示。
具体页面



举办方可以查看所有志愿者信息并进行删改操作。




本系统没有实现用户自行注册功能,需登录举办方账号,进行志愿者的添加功能,这里也同样对信息的填入做了判定,避免因填入信息为空而报错。


四、 对程序设计实践中遇到的问题进行评价和分析,给出具体体会
在本次志愿者管理系统的开发过程中,程序设计涵盖了系统架构、功能实现、数据库设计和前后端的交互等多个方面。以下是我在程序设计过程中遇到的一些问题和收获:
1) 收获:
掌握了SSM框架的使用:通过本项目,我深入了解了Spring、Spring MVC和MyBatis(SSM)框架的使用,特别是在MyBatis的配置和DAO层的实现上,我学会了如何通过SQL映射文件和注解来执行增删改查操作。
前后端分离的开发方式:前端使用JSP和CSS进行页面展示,通过表单提交数据,后端通过Spring MVC接收请求并返回相应数据。这种前后端分离的开发方式让我更好地理解了前端与后端如何进行协作,以及如何通过HTTP请求和响应传递数据。
实现了复杂业务逻辑的处理:比如报名与取消报名功能的实现,需要涉及活动库存数量的更新、报名记录的创建和更新等多个操作,这个过程让我更好地理解了如何处理多个业务逻辑之间的交互,以及如何保证数据的一致性。
2) 分析解决问题的过程:
我的问题主要出现在前端与后端的数据交互方面。由于我一开始并不熟悉它们之间的数据传递过程和页面请求过程,导致页面经常报错,出现HTTP 404和500等情况。我发现这是由于前端和后端在数据格式、请求方式以及接口的定义上存在差异,造成了数据传递不完整或格式不匹配的错误。例如,前端发送的日期格式与后端的格式不一致,或者前端未能正确传递必需的参数,导致系统出错。这些问题不仅影响了开发进度,也让我对前后端分离和接口交互的理解产生了困惑。通过不断检查代码、调试以及查阅相关文档,我逐步规范了数据格式和接口约定,确保了前后端的数据传递和处理都能顺畅进行。我还因此学会了如何使用开发者工具来调试和测试前后端交互,进一步提高了对接口调试和错误排查的能力。但由于个人时间精力有限,虽然一开始写了用户自行注册和举办方信息OrganizerInfo的部分相关代码,却未能实现完整的效果。
1244

被折叠的 条评论
为什么被折叠?



