SpringMVC+JSP+MySQL宿舍管理系统毕设实战详解

这段时间帮几个学弟拾掇毕业设计，发现一个有意思的现象：十个Java Web选题里，至少有六七个是“学生××管理系统”的路数，而其中被点名频率极高的，就是基于SpringMVC+JSP+MySQL这套组合的宿舍管理系统。你说它技术新吧，确实不算新，SpringBoot都流行多少年了；可你要说它过时，每年答辩台上照样有一批人靠它稳稳过关。

这套系统之所以长盛不衰，背后的逻辑其实很务实：技术栈经典、功能边界清晰、代码量适中、业务贴近校园场景，老师一看就懂，学生也好上手改。但“好做”不等于“做得好”，我见过太多把登录、增删改查写成一团乱麻的提交版本。这篇文章就把宿舍管理系统从选型、数据库设计、三层架构代码骨架、JSP页面渲染，到MySQL建库和Tomcat部署的完整链路捋一遍，把我帮人改项目时积累的实际经验一并放进去，准备做毕设或者想拿这套系统练手的朋友可以直接照着走。

1. 毕设技术栈的选型逻辑：SpringMVC+JSP到底还值不值得用

1.1 为什么毕设项目偏爱这套老组合

先别急着吐槽JSP过时。在很多学校的毕设选题库里，SpringMVC+JSP+MySQL依然是默认推荐配置，原因非常现实：第一，教学体系里SpringMVC是SSM框架阶段的核心内容，课程设计、实训作业都围绕它展开，学生对它最熟；第二，JSP作为服务端页面技术，天然支持Java代码嵌入，业务逻辑和页面展示之间没有额外的中间层，调试起来直观；第三，这套组合的资料极度丰富，遇到问题搜索一下基本都有现成答案，对赶DDL的学生来说，可查性和可复现性就是生命线。

从老师评审的角度看，SpringMVC体现的MVC分层思想、DAO模式、拦截器机制，都是“有技术含量”的考察点，比纯Servlet+JDBC的demo高级一档，又比SpringBoot那种“配置都给你藏起来”的黑盒风格更容易在答辩时讲清楚原理。说白了，毕设考察的是你对这套请求处理链路有没有真正理解，而不是你用了多新的框架。把DispatcherServlet怎么分发请求、HandlerInterceptor怎么拦截未登录用户讲明白，比甩出一句“我用了SpringBoot自动配置”更能扛住提问。

1.2 和SpringBoot相比，同样需求差在哪

有人会问：既然做宿舍管理系统，为什么不直接用SpringBoot？差别主要在两个方面。一是配置方式的差异，SpringBoot用自动配置和application.yml把数据源、视图解析器、包扫描全部隐式搞定，写起来确实快，但很多学生根本说不清SpringBoot是如何把SpringMVC的DispatcherServlet注册进Tomcat的，答辩被追问“SpringBoot和SpringMVC什么关系”时就卡壳了。而传统SpringMVC项目里，web.xml、spring-mvc.xml、spring-context.xml每一份配置都摆在明面上，理清这些文件，你对Web容器和Spring容器之间的关系就有了实在的认知。

二是资源占用和部署形式，SpringBoot打出来的fat jar动辄几十上百兆，内嵌Tomcat启动也稍重；传统WAR包丢进外部Tomcat的webapps目录就能跑，部署过程对毕设演示来说更直观，老师还能看到你确实会配置Tomcat、处理端口和上下文路径这类基本功。当然，我并不是说SpringBoot不能选，如果题目明确要求微服务、快速开发，那另说。但就“学生宿舍管理系统”这种标准CRUD加多角色权限的选题而言，SpringMVC的工程结构反而更容易展示你的框架理解深度。

1.3 一种更稳妥的折中写法

如果你既想保留SpringMVC的经典结构，又不想代码写得太原始，我建议持久层用Spring的JdbcTemplate而不是裸JDBC，理由很简单：JdbcTemplate帮我们处理了连接的获取与释放、结果集到对象的映射、异常转译这些重复劳动，但SQL还是自己写，数据访问逻辑透明可解释。相比引入MyBatis，又少了一层mapper XML的配置和动态SQL学习成本，对时间紧张、追求稳妥的毕设场景非常友好。

下面这张表可以直观对比三门技术栈在宿舍管理系统场景下的表现：

从多年帮改项目的经验看，绝大多数中等水平的学生，选SpringMVC+JdbcTemplate是性价比最高的路径，既能写出像样的三层结构，又不会因为框架太抽象导致答辩翻车。

2. 宿舍管理系统的需求拆解与数据库建模

2.1 功能边界先划清楚：两个角色、六张核心表

动手写代码之前，先把需求边界划清楚。宿舍管理系统听起来大，但毕设级别做到“能用、完整、有亮点”就够了。我一般建议切成两个角色四类业务：

• 管理员端：学生信息管理、宿舍楼与房间管理、住宿分配/调宿、报修处理、访客登记与晚归登记、公告发布
• 学生端：查看个人住宿信息、提交报修、查看公告

不需要强行加什么线上缴费、智能门禁，功能一多，代码量翻倍，测试工作量跟着爆炸，最后交付质量反而撑不住。先把核心业务做扎实，再考虑扩展。

对应到数据库，我通常设计如下六张核心表：管理员表、学生表、宿舍楼表、宿舍房间表、住宿记录表、报修表。公告、访客、晚归可以按需再加三张，属于锦上添花。表格之间通过外键关联形成网状结构：宿舍楼一对多房间，房间一对多住宿记录，学生一对多住宿记录（通过学号关联），住宿记录又反向关联房间，报修表记录哪个学生在哪个房间报了什么故障。

2.2 从一条住宿分配记录反推表结构

很多新手建表习惯先写SQL，写着写着发现字段不够或者冗余严重。我习惯反过来，拿一条核心业务数据反推结构。以“分配学生张三入住3号楼501房间”这件事为例，需要支撑它的数据至少有：

• 学生是谁：学号、姓名、性别、学院、班级、联系电话
• 房间在哪：宿舍楼名称/编号、房间号、床位数量、已住人数、房间状态（空闲/部分入住/已满）
• 分配关系：哪个学生、哪个房间、入住时间、是否当前有效记录

于是三张表的最小字段就出来了：student表（id、stu_no、name、gender、college、class_name、phone、status）、dorm_room表（id、building_name、room_no、bed_count、occupied_count、status）、stay_record表（id、student_id、room_id、check_in_date、is_current）。住宿分配这个动作，本质上就是判断房间有没有空位、往stay_record插一条记录、同时更新room表的occupied_count。把这条链路想明白，后面Service层代码就是照着这个业务顺序写。

2.3 建库SQL里的三个易错点

数据库看似简单，翻车点反而最多。我总结三个高频问题，都是实际帮人排查过的：

第一，字段名不要用SQL保留字。有人把升降序字段命名为“desc”，把订单号命名为“order”，查询的时候SQL直接报错。宿舍管理系统里比较容易踩的坑是“group”“status”“type”这类，虽然不是严格保留字，但在某些MySQL版本和组合SQL里也会出问题。稳妥做法是加前缀，比如room_status、user_type，语义清晰又安全。

第二，字符串字段的默认值要写清楚。比如学生的status字段默认1表示正常、0表示离校，建表时最好直接DEFAULT 1，这样插入新学生时少一个赋值步骤，也不会因为Java端忘记传值导致NULL进入数据库。同理适用于gender字段，默认值建议直接给（比如’男’），查询和列表展示时少很多空指针判断。

第三，外键约束在建表时就要明确，而不是靠Java代码维持关联。宿舍分配这种强业务关联，必须把student_id和room_id的外键都建上，并且给stay_record表加一个唯一约束，防止同一个学生被重复分配当前有效床位。以下是建表SQL的核心片段，可以直接抄：

sql复制CREATE TABLE stay_record (
    id INT PRIMARY KEY AUTO_INCREMENT,
    student_id INT NOT NULL,
    room_id INT NOT NULL,
    check_in_date DATE NOT NULL,
    check_out_date DATE DEFAULT NULL,
    is_current TINYINT DEFAULT 1,
    UNIQUE KEY uk_student_current (student_id, is_current),
    CONSTRAINT fk_stay_student FOREIGN KEY (student_id) REFERENCES student(id),
    CONSTRAINT fk_stay_room FOREIGN KEY (room_id) REFERENCES dorm_room(id)
);

这个uk_student_current唯一键是实战中很实用的一招，它保证每个学生最多只能有一条当前有效住宿记录，从数据库层面杜绝了“一个人住两间房”的逻辑错误，比在Java里先查再插保险得多。

3. SpringMVC的请求流转与核心代码骨架

3.1 一次登录请求从JSP到数据库再返回的完整链路

SpringMVC学得透不透，看他能不能讲清楚一次请求的完整路径。以管理员登录为例，你在login.jsp的form里点提交按钮，浏览器向/admin/login发POST请求，Tomcat收到后根据web.xml里配置的servlet-mapping，把请求交给DispatcherServlet，这是整个流程的入口。

DispatcherServlet拿到请求后，先通过HandlerMapping找到能处理/admin/login的HandlerMethod，也就是AdminController里标注了@RequestMapping("/login")的那个方法。找到之后，DispatcherServlet又通过HandlerAdapter执行目标方法，方法里接收用户名和密码参数，调用AdminService的login方法，Service再去AdminDao里执行一条SELECT * FROM admin WHERE username=? AND password=?。SQL结果被JdbcTemplate映射成Admin对象返回，层层回传，最终Controller把登录成功标志放进ModelAndView，视图解析器InternalResourceViewResolver把逻辑视图名“redirect:/index”解析成真正的URL，浏览器发生重定向，显示系统主页。

这条链路上最容易被忽略的是DispatcherServlet默认只扫描spring-mvc.xml里配置的包，Service和Dao的Bean如果放在另一个context配置文件里，必须在web.xml同时加载，否则启动时报找不到Service的Bean，实际运行到登录就报500。这种问题我见得太多，配置文件和源码同样重要。

3.2 Controller、Service、DAO三层的代码长什么样

很多人写三层架构写着写着就缩水成“Controller包一切”，Service和DAO形同虚设。既然毕设要讲分层思想，代码结构就得立得住。以宿舍分配为例，正确做法是Controller只负责参数接收和视图跳转，分配业务的规则判断放在Service层，数据落库在DAO层。

Controller示例：

java复制@Controller
@RequestMapping("/stay")
public class StayRecordController {

    @Autowired
    private StayRecordService stayRecordService;

    @RequestMapping("/assign")
    public String assign(@RequestParam Integer studentId,
                         @RequestParam Integer roomId,
                         Model model) {
        String result = stayRecordService.assignRoom(studentId, roomId);
        model.addAttribute("message", result);
        return "redirect:/stay/list";
    }
}

Service层承载核心逻辑，判断房间是否有空位、学生是否已有住宿记录都要在这里完成：

java复制@Service
public class StayRecordServiceImpl implements StayRecordService {

    @Autowired
    private DormRoomDao dormRoomDao;

    @Autowired
    private StayRecordDao stayRecordDao;

    @Override
    public String assignRoom(Integer studentId, Integer roomId) {
        DormRoom room = dormRoomDao.findById(roomId);
        if (room == null) {
            return "房间不存在";
        }
        if (room.getOccupiedCount() >= room.getBedCount()) {
            return "房间已满，分配失败";
        }
        if (stayRecordDao.findCurrentByStudentId(studentId) != null) {
            return "该学生已有住宿记录";
        }
        stayRecordDao.insert(new StayRecord(studentId, roomId, new Date()));
        dormRoomDao.increaseOccupiedCount(roomId);
        return "分配成功";
    }
}

DAO层用JdbcTemplate写就行了，核心方法就是根据条件查记录、插入记录、更新计数，SQL简练明确。三层各司其职，答辩的时候被问“改需求怎么改”，你可以说“用户新加一个退宿功能，只需要在Service里加方法，Controller只管暴露URL”，这就是分层的价值。

3.3 用拦截器把未登录用户挡在页面外

SpringMVC拦截器是毕设里的高频加分项，也是搜索引擎里经常被查的知识点。宿舍管理系统里，除了登录页和静态资源，其余URL都应该校验Session，未登录一律重定向到登录页。

先写一个HandlerInterceptor实现类：

java复制public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        Object admin = request.getSession().getAttribute("admin");
        if (admin == null) {
            response.sendRedirect(request.getContextPath() + "/login");
            return false;
        }
        return true;
    }
}

然后在spring-mvc.xml里注册拦截器并配置放行路径：

xml复制<mvc:interceptors>
    <mvc:interceptor>
        <mvc:mapping path="/**"/>
        <mvc:exclude-mapping path="/login"/>
        <mvc:exclude-mapping path="/css/**"/>
        <mvc:exclude-mapping path="/js/**"/>
        <mvc:exclude-mapping path="/images/**"/>
    </mvc:interceptor>
</mvc:interceptors>

这段配置看起来简单，但放过静态资源非常关键，不然你会发现登录页没样式、图片加载不出来，排查半天才发现是拦截器把静态资源也拦了。另外要注意，如果系统有学生端，建议再写一个学生端拦截器，按角色区分权限，这也是答辩时“权限管理”这个考点的重要支撑。

4. JSP页面和前端交互的实操细节

4.1 用<c:forEach>循环渲染宿舍列表

JSP页面的核心工作是把后台数据变成用户看得懂的界面。宿舍列表页是最典型的场景：Controller把List<DormRoom>放进Model，JSP页面用JSTL标签遍历输出。重点在于每行数据要同时展示“房间号、床位总数、已住人数、状态”，状态列还要根据occupied_count动态变化。

jsp复制<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<table class="table table-bordered">
    <thead>
        <tr>
            <th>房间号</th>
            <th>床位</th>
            <th>已住</th>
            <th>状态</th>
            <th>操作</th>
        </tr>
    </thead>
    <tbody>
        <c:forEach items="${roomList}" var="room">
            <tr>
                <td>${room.buildingName} - ${room.roomNo}</td>
                <td>${room.bedCount}</td>
                <td>${room.occupiedCount}</td>
                <td>
                    <c:choose>
                        <c:when test="${room.occupiedCount == 0}">
                            <span class="label label-success">空闲</span>
                        </c:when>
                        <c:when test="${room.occupiedCount >= room.bedCount}">
                            <span class="label label-danger">已满</span>
                        </c:when>
                        <c:otherwise>
                            <span class="label label-warning">部分入住</span>
                        </c:otherwise>
                    </c:choose>
                </td>
                <td>
                    <a href="${pageContext.request.contextPath}/stay/assign?roomId=${room.id}">分配</a>
                </td>
            </tr>
        </c:forEach>
    </tbody>
</table>

这里有一个很实用的细节：所有链接的路径都要用${pageContext.request.contextPath}拼接上下文路径。很多新手习惯写死/dorm/xxx，部署的时候如果把WAR包改名或者改Tomcat的虚拟路径，所有链接全部404，而用EL表达式动态拼接就不会有这个问题。JSP里嵌入EL表达式和JSTL是标准做法，注意不要用Java脚本片段<% %>，既丑又难维护，答辩时印象分也低。

4.2 分页查询怎么做才算及格

列表数据一多就得分页。毕设级别的分页不用引PageHelper这种插件，手写一个简单分页反而更能展示基本功。思路是：页面传两个参数，currentPage和pageSize，Service层先查总记录数算出总页数，再查当前页的数据，把三样东西（当前页数据、总页数、当前页码）封装成一个PageModel放进Model。

java复制public class PageModel<T> {
    private List<T> list;
    private int currentPage;
    private int pageSize;
    private int totalPage;
    private int totalCount;
}

DAO层配合MySQL的LIMIT实现：

sql复制SELECT * FROM student LIMIT ?, ?

分页在SQL层面就是offset和limit两个参数，offset=(currentPage-1)*pageSize。实际操作中要注意一个边界：总记录数除以pageSize时，如果不能整除，总页数要加一，这个细节很多人漏掉，导致最后一页数据被截断。JSP里的分页条一般就是上一页、页码数字、下一页三个部分，点击链接时把currentPage作为参数传给Controller。

4.3 页面刷新和数据回显的两个小坑

做JSP页面我另外提醒两个小坑，都是实际踩过的。一个是在form提交后立即做整页刷新，靠浏览器刷新按钮重新POST，导致重复提交。正确做法是Controller处理完业务后一律用redirect:重定向，这样刷新的是GET结果页而不是POST请求，既避免了重复插入数据，也更符合Post/Redirect/Get模式。

另一个是修改学生信息时表单回显。后端把要修改的Student对象传入页面，input的value属性直接用${student.name}输出。但性别这种单选按钮或者下拉框的回显，要多写一个判断逻辑，比如性别为男时，男这个radio要加上checked属性。这个判断可以用JSTL的${student.gender == '男' ? 'checked' : ''}来生成，虽然没有Vue那种双向绑定方便，但逻辑清清楚楚，也完全够用。

5. 部署全流程：从MySQL建库到Tomcat跑通

5.1 数据库初始化：5.7还是8.0，连接参数怎么写

宿舍管理系统对数据库版本不敏感，5.7和8.0都能跑，但连接参数有区别。5.7一般用com.mysql.jdbc.Driver，8.0要用com.mysql.cj.jdbc.Driver；另外8.0的连接URL必须加时区参数，否则会报The server time zone value异常。我习惯统一用8.0的驱动写法，即使在5.7上也能正常运行，兼容性强：

java复制jdbc.driver=com.mysql.cj.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/dorm?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
jdbc.username=root
jdbc.password=你的密码

给新手的建议是：直接用官方安装包装MySQL 8.0，安装过程中选UTF-8字符集（或者装完后单独指定）。执行数据库脚本时，推荐在命令行里用mysql -uroot -p < dorm.sql这种方式导入，比你复制粘贴到Navicat的查询窗口更不容易出错，而且ID自增、外键关系都能完整保留。导入完成后用SHOW TABLES;检查一下六张核心表是否齐全。

5.2 项目打包与Tomcat部署

传统的SpringMVC项目一般打成WAR包部署。如果你用的是Eclipse/IDEA，构建时会自动生成WAR文件，也可以直接用Maven的mvn clean package。拿到WAR包以后，把它复制到Tomcat的webapps目录下，启动Tomcat，它会自动解压部署，访问路径就是http://localhost:8080/项目名/。

如果没有自动解压，最常见的原因是webapps目录没有写权限，Windows下用管理员身份启动Tomcat，Linux下chmod一下目录权限就能解决。另外提醒一句，虽然我前面建议用WAR包方式，但如果你的环境里Tomcat版本高，去配置Manager应用部署也可以，本质是一样的，别在部署形式上纠结太久。

5.3 部署阶段最常碰到的三个问题排查

部署阶段的问题，99%集中在连接、路径和依赖这三类上。我把排查经验整理成表，方便对照：

我发现一个频繁发生的事情：学生用IDEA部署时，项目引用的jar包只有IDEA知道，Tomcat的WEB-INF/lib下根本没有，一打包部署就缺依赖。所以WAR包部署之前，一定要打开压缩包看一眼WEB-INF/lib目录，缺jar就在Project Structure里把依赖加进去重新构建。这个习惯能帮你省掉大量无谓的排查时间。

6. 数据初始化和演示数据准备的一些经验

宿舍管理系统这种项目，交上去和演示的时候，空数据库是要扣印象分的。老师评审的时候打开学生列表，如果里面空空如也，系统的“完整性”观感会大打折扣。我建议在SQL脚本里预置两批数据：一批是管理员账号（admin/123456这类），登录演示用；另一批是模拟数据，比如20个学生、8个房间、若干条住宿记录和报修记录，让页面一打开就有东西看。

模拟数据要造得自然一点，学院、班级、姓名尽量分布均匀。这里有个取巧的办法，宿舍管理系统是典型的“程序生成数据比手写舒服”的场景，用Excel拉一批学号，写SQL的INSERT INTO时直接拼接，一次性生成几十条记录。不要手写。报修数据的日期最好贴近演示时间，看起来更真实，老师问起来你也能说这是最近一周的业务数据。

7. 从部署到答辩：一条龙准备的优先级排序

项目能跑只是及格线，想拿高分还得安排优先级。我的经验是把时间按这个比例分配：系统功能完整度、代码结构规范性、部署可运行性、文档一致性、演示脚本熟练度。很多学生花大量时间调页面样式，却忽视了一个最要命的问题——论文里的SQL语句字段和实际数据库不一致、操作截图和实际页面不一样。这类不一致在答辩时会被老师直接判定为“敷衍”。

我的习惯是：先把系统跑通，录一遍操作流程，截图放论文；再回头核对论文里每一个界面截图、每一段配置代码和实际操作完全一致；然后多演示几遍，把报修流程、分配流程、权限拦截这三个高频演示场景练熟。答辩时能把这三点讲清楚，拿个良好以上问题不大。

最后说点实在的，这套系统做完之后，别急着扔进网盘吃灰。它是你理解Java Web请求从浏览器到数据库一个完整闭环的活教材，面试的时候被问到SpringMVC核心组件、拦截器实现思路、数据库表设计原则，都可以直接拿这个项目当素材回答。带着“做项目不如做懂一个项目”的心态去打磨，你收获的绝对不止一个合格分数。