基于Spring Boot的大创管理系统:角色权限与状态机驱动的全流程设计

发布时间:2026/10/28 19:13:51
基于Spring Boot的大创管理系统:角色权限与状态机驱动的全流程设计 简介这份资源是面向计算机专业毕业生的大创管理系统毕业论文文档基于Spring Boot与SSM框架开发适合正在准备毕业设计或课程设计的学生参考。文档完整呈现了从摘要、背景意义、需求分析、可行性分析到数据库设计、数据流图、详细设计、系统测试与总结的论文结构并围绕学生、指导老师、院系管理员三类角色展开项目申报、中检、结项、评审等功能设计可帮助读者理清论文写作逻辑与系统实现思路。压缩包内共1个doc文件约2.57MB内容涵盖ER图、数据字典、系统截图等论文必备素材。目前已有134人学习适合需要参考完整论文框架与技术方案的同学使用。1. 从一份“改到第三版还在返工”的申报表说起每年大创申报季最让院系管理员头疼的不是评审本身而是那张在群里传来传去的申报表——学生填完发邮件老师下载改完再回传版本号从 v1 排到 v7最后谁也说不清哪份是终稿。这套基于 Spring Boot 的大创管理系统要解决的就是这类“流程在线下、数据在表里、责任在嘴上”的老问题。它面向三类人需要交毕设或课设的学生、要落地一套院系级项目管理流程的开发者以及正在找“管理系统类论文怎么写才不空”的参考者。整套方案把申报、中检、结项、评审四条主线收进一个 B/S 系统用角色权限把责任切清楚让每个环节的状态可查、可追、可导出。2. 需求与角色拆解三个角色、四条主线怎么划清边界2.1 先定角色再谈功能管理系统类项目最容易翻车的地方是一上来就画功能树结果学生能改评审结果、老师能替学生申报权限形同虚设。这套系统的做法是先锁死三个角色学生、指导老师、院系管理员。学生只碰“我自己的项目”——申报、查看中检通知、提交结项材料、看评审结论指导老师管“我名下的项目”——审核申报、组织中期检查、给出评审意见、维护评审方案院系管理员管“全院的盘子”——项目类型、优秀项目、资讯发布、专家库、评审方案模板。这个划分的关键在于同一张业务表不同角色看到的字段和可执行的动作不一样。比如项目申报表学生看到的是“提交/撤回”老师看到的是“通过/驳回”管理员看到的是“汇总/导出”。实现上不靠前端藏按钮而是后端每个接口都做角色校验前端只做体验层。2.2 四条主线的状态流转把功能按时间轴串起来其实是四条状态机主线起点状态中间状态终点状态触发角色项目申报草稿待审核 / 已驳回审核通过学生提交、老师审核项目中检待提交已提交 / 需整改中检通过学生提交、老师评定项目结项待提交已提交 / 延期结项完成学生提交、老师审核项目评审待分配评审中已出分管理员分配、专家打分状态字段建议用整型枚举而不是字符串避免“待审核”“待审核 ”这种带空格的脏数据。每次状态变更写一条操作日志记录操作人、时间、前后状态——这是后期答辩时最容易被问“你怎么保证流程可追溯”的答案。2.3 非功能性需求别漏论文里常被忽略、答辩时必被问的三点一是并发量院系级系统通常几十人同时在线不需要分布式但连接池要配好二是数据完整性项目表的外键要指向用户表和类型表删除类型前先校验是否被引用三是安全性密码不能明文存登录接口要限流越权访问要在拦截器层拦掉。这三点写进需求分析章节比堆十页“研究背景”有用得多。3. 技术选型与总体架构为什么是 Spring Boot SSM MySQL3.1 选型逻辑够用、能讲清、好维护这套系统采用 B/S 结构后端 Spring Boot 整合 SSMSpring SpringMVC MyBatis数据库 MySQL前端 JSP 或模板引擎渲染。选型理由不是“先进”而是三点第一Spring Boot 的自动配置把数据源、事务、拦截器的样板代码压到最低一个application.yml就能起服务适合毕设周期第二MyBatis 的 XML 映射对“多表关联查询 条件分页”这类管理系统的典型需求最直接SQL 写在明面上调试时不用猜 ORM 生成了什么第三MySQL 开源、资料多、部署轻答辩演示时本机就能跑。提示论文里写“采用 SSM 框架”时要说明 Spring Boot 是外层整合者SSM 是内部三层结构两者不是并列关系否则容易被追问“到底用的哪个”。3.2 三层结构与模块职责整体分三层表现层负责页面渲染和表单校验控制层负责接收请求、做角色鉴权和参数绑定服务层负责业务规则状态流转、权限判断、事务持久层用 MyBatis Mapper 对接 MySQL。模块按业务切分用户与权限模块、项目申报模块、中检模块、结项模块、评审模块、资讯与优秀项目模块、文件上传模块。一个典型的请求链路是学生点“提交申报” → 控制层校验登录态和角色 → 服务层检查项目状态是否为“草稿” → 更新状态为“待审核”并写日志 → 返回结果。这条链路里状态校验必须放在服务层不能只靠前端按钮置灰否则绕过页面直接调接口就能改状态。3.3 关键配置示例# application.yml 核心配置 spring: datasource: url: jdbc:mysql://localhost:3306/dachuang?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 10 # 院系级并发足够别开太大 connection-timeout: 30000 servlet: multipart: max-file-size: 10MB # 申报附件上限 max-request-size: 20MB mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true # 下划线字段自动映射驼峰属性这段配置里两个参数值得在论文里点一句连接池上限设 10 是因为院系级系统同时在线人数有限开太大反而浪费数据库连接map-underscore-to-camel-case打开后数据库的add_time能自动映射到实体类的addTime省掉大量resultMap手写。文件大小限制要和前端提示保持一致否则学生传 15MB 的 PDF 会得到一个看不懂的 500 错误。4. 数据库设计与核心表落地从 E-R 到建表语句4.1 实体识别与关系按业务抽实体用户含角色字段、项目类型、项目信息、项目申报、项目中检、项目结项、评审方案、专家评审、优秀项目、大创资讯、操作日志。核心关系是一个用户可申报多个项目一个项目属于一个类型、对应一条申报记录、可有多条中检和结项记录一个评审方案下可分配多个专家评审。E-R 图在论文里要画清楚三组关系用户与项目的“一对多”、项目与评审的“一对多”、类型与项目的“一对多”。很多同学只画实体不画联系答辩时被问“项目和评审怎么关联”就卡住。4.2 核心建表语句-- 项目信息表业务主表其他流程表都挂它 CREATE TABLE project_info ( id BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 主键, project_name VARCHAR(200) NOT NULL COMMENT 项目名称, type_id BIGINT(20) NOT NULL COMMENT 项目类型外键, student_id BIGINT(20) NOT NULL COMMENT 申报学生, teacher_id BIGINT(20) DEFAULT NULL COMMENT 指导老师, status TINYINT(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1待审核 2已通过 3已驳回, add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_student (student_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT项目信息; -- 操作日志表状态可追溯的关键 CREATE TABLE operate_log ( id BIGINT(20) NOT NULL AUTO_INCREMENT, biz_type VARCHAR(50) NOT NULL COMMENT 业务类型申报/中检/结项, biz_id BIGINT(20) NOT NULL COMMENT 业务主键, from_status TINYINT(4) DEFAULT NULL, to_status TINYINT(4) NOT NULL, operator_id BIGINT(20) NOT NULL, remark VARCHAR(255) DEFAULT NULL, create_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_biz (biz_type, biz_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT操作日志;建表时三个细节决定后期返工量字符集统一utf8mb4否则学生姓名里的生僻字会变问号状态字段用TINYINT加注释比VARCHAR省空间且不会出现拼写不一致高频查询字段学生 ID、状态建索引列表页分页查询才不会随数据量增长变慢。日志表单独建而不是塞进业务表是为了让“谁在什么时候把状态从几改成几”这条链完整保留答辩演示时直接查这张表就能讲清流程。4.3 分页查询的 Mapper 写法!-- ProjectInfoMapper.xml 片段按角色和状态分页 -- select idselectPage resultTypeProjectInfoVO SELECT p.*, t.type_name, u.real_name AS studentName FROM project_info p LEFT JOIN project_type t ON p.type_id t.id LEFT JOIN sys_user u ON p.student_id u.id where if testrole studentAND p.student_id #{userId}/if if testrole teacherAND p.teacher_id #{userId}/if if teststatus ! nullAND p.status #{status}/if /where ORDER BY p.add_time DESC LIMIT #{offset}, #{pageSize} /select这段 SQL 的设计点是角色过滤放在 SQL 层而不是查出来再过滤避免把无权限数据传到前端LEFT JOIN保证类型或用户被删时项目记录仍能显示LIMIT分页配合前面的索引数据量上千后性能差异明显。参数说明offset (pageNum - 1) * pageSizepageSize建议服务端限制上限 50防止前端传个 10000 把数据库拖垮。5. 核心模块实现申报、中检、结项、评审怎么串起来5.1 申报提交与审核的状态机实现申报模块的核心不是表单是状态流转的合法性。学生只能对“草稿”或“已驳回”的项目执行提交老师只能对“待审核”的项目执行通过或驳回。服务层用一个方法收口// ProjectService.java 片段 Transactional public void changeStatus(Long projectId, Integer targetStatus, Long operatorId, String remark) { ProjectInfo p projectMapper.selectById(projectId); if (p null) throw new BizException(项目不存在); // 合法流转表key 当前状态value 允许的目标状态集合 MapInteger, SetInteger allow Map.of( 0, Set.of(1), // 草稿 - 待审核 1, Set.of(2, 3), // 待审核 - 通过/驳回 3, Set.of(1) // 驳回 - 重新提交 ); if (!allow.getOrDefault(p.getStatus(), Set.of()).contains(targetStatus)) { throw new BizException(当前状态不允许此操作); } projectMapper.updateStatus(projectId, targetStatus); logMapper.insert(new OperateLog(申报, projectId, p.getStatus(), targetStatus, operatorId, remark)); }这段代码的价值在于把“什么状态能变成什么状态”写成一张显式的表而不是散落在各个 if 里。后期加“延期”状态时只改这张表不用翻遍所有接口。Transactional保证状态更新和日志写入要么都成功要么都回滚避免出现“状态变了但没日志”的黑匣子情况。5.2 中检与结项的附件与时限控制中检和结项都涉及材料上传和时间窗口。实现上分两步上传接口只负责存文件、返回文件路径业务接口负责把路径写进对应记录并校验时间。时间校验放在服务层用配置项控制窗口期// 中检提交前校验是否在开放窗口内 LocalDateTime now LocalDateTime.now(); if (now.isBefore(config.getMidCheckStart()) || now.isAfter(config.getMidCheckEnd())) { throw new BizException(当前不在中检提交时间内); }窗口期做成配置而不是硬编码是因为每学期时间不同管理员在后台改两个日期就能调整不用重新部署。附件存储建议按“业务类型/年月/随机文件名”分目录原始文件名存数据库既避免同名覆盖也防止学生上传的文件名带特殊字符导致下载异常。5.3 评审方案与专家打分的解耦评审模块容易写成一坨方案、专家、打分、汇总全挤在一张表。这套系统的做法是拆成三张表——评审方案表存评分维度和权重专家评审表存“哪个专家评哪个项目、状态如何”评分明细表存每个维度的分数。打分时按方案里的维度动态渲染表单汇总时按权重加权。这样拆的好处是换一套评审方案不用改代码管理员新建方案、重新分配专家即可专家打分和最终成绩解耦后期要加“去最高最低分”的规则也只动汇总逻辑。论文里讲这块时重点画清楚三张表的关系比贴大段代码更能体现设计能力。5.4 权限拦截器越权访问的统一出口// AuthInterceptor.java 片段 Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) { String uri req.getRequestURI(); // 白名单登录、静态资源 if (uri.startsWith(/login) || uri.startsWith(/static)) return true; Object user req.getSession().getAttribute(loginUser); if (user null) { resp.sendRedirect(/login); return false; } // 角色前缀校验/admin/** 仅管理员/teacher/** 仅老师 String role ((User) user).getRole(); if (uri.startsWith(/admin) !admin.equals(role)) { resp.setStatus(403); return false; } return true; }拦截器统一处理登录态和角色前缀业务代码里就不用每个方法都写一遍判断。注意白名单要精确匹配前缀别写成uri.contains(login)否则/admin/deleteLoginUser这种路径会被误放行——这是血泪经验里最常见的一类漏洞。6. 避坑与常见问题那些答辩前才暴露的坑6.1 状态字段用字符串后期统计全乱现象列表页筛选“待审核”查不到数据数据库里同时存在“待审核”“待审核 ”“待 审核”。原因前端下拉框传值不统一后端又没做枚举约束。解决状态一律用整型枚举前端只传数字后端用常量类收口数据库字段加注释说明每个数字含义。6.2 文件上传路径写死在本机绝对路径现象换台电脑演示附件全部 404。原因上传目录写成了D:/upload/。解决路径配置在application.yml里用相对路径或可配置的根目录读取时通过配置注入。演示前把上传目录随项目一起拷贝或者改成项目内./upload。6.3 分页查询没加角色条件学生看到全院项目现象学生登录后列表里出现别人的项目。原因Mapper 里角色过滤的if条件写错或者控制层没把当前用户 ID 传进去。解决在服务层统一封装“当前用户 角色”的查询上下文Mapper 强制接收并在测试用例里专门验证“学生 A 查不到学生 B 的数据”。6.4 事务注解加在控制层回滚不生效现象状态更新成功但日志没写进去数据不一致。原因Transactional加在 Controller 方法上或者同类内部方法调用绕过代理。解决事务注解只加在 Service 的 public 方法上跨方法调用通过注入自身代理或拆分服务类解决。6.5 密码明文存储答辩被一问就慌现象数据库里能直接看到密码。原因注册时直接存了原值。解决注册和改密时用 BCrypt 加密登录时用matches比对。这个改动量很小但体现的是基本的安全意识答辩时主动讲出来是加分项。7. 验收与答辩怎么用一张状态流转图讲清整个系统验收这套系统我一般不看功能列表有多长而是走三条链路第一条新学生注册→申报项目→老师驳回→学生改完重提→老师通过全程查操作日志是否连续第二条管理员建评审方案→分配专家→专家打分→汇总成绩检查权重计算是否正确第三条用学生账号直接访问/admin/开头的接口确认返回 403 而不是页面。三条链路走通功能验收基本就稳了。答辩时的技巧是别按菜单讲功能按状态讲流程。准备一张图横轴是四条主线纵轴是状态节点每个节点标注“谁能操作、操作后写什么日志、异常时怎么回退”。评委问“你怎么保证数据一致性”就指着状态机和事务注解回答问“权限怎么控制”就讲拦截器加服务层双重校验问“工作量在哪”就展示日志表和评审方案的可配置设计。测试章节也别只写“功能测试通过”补一张表测试项输入预期实际结论越权访问学生 token 调管理员接口403403通过重复提交连续两次点提交第二次提示状态非法符合通过附件超限上传 15MB 文件提示超出限制符合通过这张表比十页文字描述更能说明你测过边界。最后说个习惯从那以后我每次交方案前都会用一个全新账号从注册走到结项全程不碰数据库、不改代码只靠页面操作——凡是走不通的地方就是评委一定会问的地方。希望帮到你。本文还有配套的精品资源点击获取

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询