做评教系统这类项目最容易被低估的是需求没那么简单。表面上看无非是学生打分、老师看分、管理员管指标但真正动手之后你会发现权限边界、重复提交、统计口径、事务边界每一个点都能让你改到怀疑人生。SSM273这套教学质量评价评教系统我前前后后从原型到完整落地花了两周左右这里把整个设计思路、核心实现和踩过的坑都整理出来给准备做同类项目的人一个参考。这套系统的价值在于它不是一个纯CRUD的玩具。评教数据涉及多角色、多学期、多指标而且最终要输出教学质量的量化排名这意味着数据模型必须严谨SQL必须经得起推敲前后端交互也有不少细节。无论你是拿它当课程设计、毕业设计还是想把它改造成真实可用的教务工具下面这些内容都值得看一遍。1. 评教系统的需求边界先想清楚三个角色再写代码1.1 三个角色的权限边界评教系统最忌讳一上来就建表写接口。我见过不少同学把学生、教师、管理员全部塞进一张user表字段一长串登录之后靠一个role字段判断跳转结果权限越做越乱改一处崩三处。这个项目里我的做法是先定义清楚每个角色能做什么、不能做什么再让代码去落实这些规则。学生查看当前学期需要评教的课程与教师填写评价表并提交仅可查看自己的历史提交记录不允许修改已提交的评价。教师查看自己被评价的平均分、各项指标得分和排名不能查看具体是哪个学生打了分也不能修改系统中的评价指标。管理员教务处管理学生、教师、课程基础数据配置评价指标和权重发布/关闭评教学期查看全院的统计报表。这条边界划完之后整个系统的功能菜单基本就定型了学生端是一个待评教列表 评价表单 我的评价记录教师端是我的评价结果 排名对比管理员端是四大基础管理模块加一个统计中心。1.2 功能清单与页面流转落实到具体功能系统分成下面几个模块模块使用角色核心功能关键约束登录认证全部账号密码登录、角色跳转未登录拦截、同一账号限制一处登录评教管理学生待评教列表、评价表单提交一个学生对同一教师同一学期只能评一次指标管理管理员指标增删改查、权重配置权重总和需校验停用指标不影响历史数据统计报表管理员、教师平均分统计、指标细项得分、排名按学期过滤支持导出基础数据管理员学生、教师、课程、班级管理数据导入时可批量操作页面流转上比较常规登录页 → 按角色进入不同主页 → 列表页 → 操作页。真正花心思的不是页面多华丽而是每个操作背后的业务规则是否闭环。比如学生提交评教之后这个教师这节课在待评教列表里必须立刻消失否则就会出现重复提交的漏洞。1.3 为什么评教系统适合练SSM抛开业务本身SSM273这个项目对学习Spring、SpringMVC、MyBatis的人来说友好度相当高Spring的依赖注入和声明式事务在Service层用得非常集中能直观理解容器管理对象的意义SpringMVC的拦截器、参数绑定、异常处理都有自然的落点尤其是登录拦截这个刚需功能能帮你彻底搞清楚拦截器的执行时机MyBatis的动态SQL在统计报表这种查询条件不固定的场景里近乎是量身定做学一遍就能记住 和 的意义。换句话说评教系统横跨了典型的CRUD、复杂的多表关联查询、权限控制和数据统计正好覆盖SSM项目里最常见的几类编码场景。把这套系统啃下来再去接触其他业务系统会发现套路都差不多。2. SSM三件套如何各司其职配置和分工别搞成一锅炖2.1 Spring负责的是对象之间的契约很多新手把框架集成理解为导入一堆依赖然后写代码结果Service里手动new了一个Mapper事务注解完全失效。SSM集成最关键的一点是明白Spring容器在这个项目里的角色它统一管理Service、Mapper等组件的生命周期也负责生成代理对象来完成事务控制。我的applicationContext.xml里核心配置大致是这样context:component-scan base-packagecom.ssm273 context:exclude-filter typeannotation expressionorg.springframework.stereotype.Controller/ /context:component-scan bean iddataSource classcom.alibaba.druid.pool.DruidDataSource init-methodinit destroy-methodclose property namedriverClassName valuecom.mysql.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/eval_db?useUnicodetrueamp;characterEncodingutf8amp;serverTimezoneAsia/Shanghai/ property nameusername valueroot/ property namepassword value123456/ property nameinitialSize value2/ property namemaxActive value20/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ property nametypeAliasesPackage valuecom.ssm273.entity/ property nameconfiguration bean classorg.apache.ibatis.session.Configuration property namemapUnderscoreToCamelCase valuetrue/ /bean /property /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.ssm273.mapper/ /bean tx:annotation-driven transaction-managertransactionManager/ bean idtransactionManager classorg.springframework.jdbc.datasource.DataSourceTransactionManager property namedataSource refdataSource/ /bean注意component-scan里要排除ControllerController的扫描交给SpringMVC的子容器否则会出现重复实例化、事务配置混乱的问题。这个细节几乎每个SSM项目都会遇到但确实不是所有人都说得清为什么。2.2 SpringMVC的请求链路拦截器是权限的守门员SpringMVC在这套系统里做的事情可以拆成三段请求进入、参数处理、响应返回。连接三段的除了DispatcherServlet还有拦截器。评教系统的登录校验、角色校验都放在拦截器里做而不是在每个Controller方法里重复判断。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); Object user session.getAttribute(loginUser); if (user null) { if (isAjaxRequest(request)) { response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录或会话过期\}); } else { response.sendRedirect(request.getContextPath() /login); } return false; } return true; } }这里有一个我后来才注意到的坑AJAX请求被拦截后如果直接重定向前端拿到的其实是登录页的HTML而不是预期的JSON页面表现就是突然跳回登录页或者弹出诡异的解析错误。所以拦截器里必须判断请求类型AJAX返回401状态码由前端统一跳转登录页普通请求才做重定向。除了登录拦截角色校验我用的是另一个拦截器根据用户role字段判断接口访问权限。管理员接口加/admin/**前缀教师接口加/teacher/**前缀学生接口加/student/**前缀拦截器按前缀匹配放行规则比在方法上加注解更直观也更容易统一维护。2.3 MyBatis的Mapper设计SQL放XML里逻辑留在Service层MyBatis在这套系统里最大的贡献是统计报表模块的动态SQL。比如教师端要按学期查看自己的得分管理员端要按学期、按学院、按指标类型多条件组合筛选条件组合少说也有十几种如果用JDBC拼接SQL代码会变成灾难。MyBatis的 、 、 标签可以很优雅地解决select idselectEvalStats resultTypejava.util.Map SELECT t.teacher_name, AVG(e.score) AS avg_score, COUNT(DISTINCT e.student_id) AS eval_count FROM eval_record e JOIN teacher t ON e.teacher_id t.id where if testsemesterId ! null AND e.semester_id #{semesterId} /if if testcollegeId ! null AND t.college_id #{collegeId} /if if testteacherId ! null AND e.teacher_id #{teacherId} /if /where GROUP BY t.id, t.teacher_name ORDER BY avg_score DESC /selectMapper接口只暴露方法签名SQL和结果映射全在XML里。结果集用Map接收对于报表类查询很方便但如果字段多我会建议定义专门的统计VO避免Map取值的魔法字符串散落在Service层各处后期改字段名会非常痛苦。2.4 配置文件的另一个关键细节数据库连接池连接池我用的是Druid不仅是因为它提供监控页面更重要的是在开发环境下能直观看到连接池的使用情况。之前用默认配置跑批量导入碰到过连接数暴涨的问题后来在配置里加了initialSize、maxActive和maxWait并且开启了testWhileIdle连接池才稳定下来。连接池参数不是越大越好核心是让连接的获取、归还、空闲检测形成节奏后面第5部分会详细说。3. 数据库建模评教系统的核心是一个关系网3.1 核心表结构设计评教本质上是学生—教师—课程—学期—指标五类信息之间产生的一次评分行为。所以数据库设计不能只盯着评价表要先把周边的主数据表设计好。表名用途关键字段t_student学生基本信息id, student_no, name, college_id, class_idt_teacher教师基本信息id, teacher_no, name, college_id, titlet_course课程信息id, course_no, name, creditt_teaching任课关系id, course_id, teacher_id, semester_idt_semester学期设置id, semester_name, status, start_date, end_datet_indicator评价指标id, indicator_name, score_range, weight, statust_eval_record评教记录id, student_id, teacher_id, course_id, semester_id, indicator_id, score, eval_time这里最容易犯的错误是把一次评教的多个指标得分放在一行里也就是设计成eval_record(stu_id, tea_id, indicator1_score, indicator2_score, ...)看着查询方便实际上后患无穷。指标是管理员动态配置的今天有5个指标下个学期可能变成8个表结构就得跟着改。正确的做法是指标和得分拆成独立的记录行一个指标一行这样指标配置再怎么变评价表结构都不用动。3.2 用唯一索引堵住重复评教评教业务里最重要的一个规则是同一个学生对同一个教师、同一门课程、同一个学期只能评一次。如果这个规则只靠Java代码的if判断去保证在高并发场景下一定会出现漏洞——两个请求同时通过了是否已评教的检查然后各自插入一条记录。我的方案是双保险代码层面查询校验数据库层面加唯一索引。CREATE UNIQUE INDEX uk_eval_unique ON t_eval_record(student_id, teacher_id, course_id, semester_id);有了这个唯一索引就算代码校验漏了数据库也会在插入时抛DuplicateKeyException事务回滚后数据依然完整。这里也要记得把查询是否已评教和插入评教记录放进同一个事务保证检查与写入之间的原子性。3.3 指标权重与打分规则指标表里weight字段用来计算加权总分。比如教学态度权重0.3、讲课水平权重0.4、课堂互动权重0.3三项满分均为100分那加权总分就是各项得分乘以权重之和。权重配置在管理员端保存时需要校验所有启用指标的权重之和等于1。打分规则上我用的是百分制整数而不是五星制主要原因是后续统计平均分可以保留一位小数排名对比也更精确。前端表单用滑块或输入框限制0到100的整数后端再一次校验边界防止绕过前端提交异常数据。这里需要注意一个统计口径如果部分学生只评了部分指标或者在某个学期某个教师只有极少几个学生参评平均分很容易失真。我给教师端统计结果加了一个参评人数的展示并且在前端用颜色标记参评人数少于10人的数据提醒看报表的人自行判断数据的参考价值。这个细节虽然不复杂但在真实使用场景里非常关键。4. 核心业务链路落地从登录到统计报表的完整代码路径4.1 登录与角色跳转登录接口的逻辑并不复杂但有几个点值得展开。密码存储我用的MD5加盐而不是明文。虽然MD5在安全强度上已经不算高但对于课程设计或内部系统加盐后的MD5已经能挡住大部分低水平攻击。如果你对安全有更高要求可以换成SHA-256或BCrypt替换成本并不高。Controller public class LoginController { Autowired private UserService userService; PostMapping(/login) public String login(String username, String password, String role, HttpSession session, Model model) { String encrypted DigestUtils.md5DigestAsHex((password SALT).getBytes()); User user userService.login(username, encrypted, role); if (user null) { model.addAttribute(msg, 用户名或密码错误); return login; } session.setAttribute(loginUser, user); if (admin.equals(user.getRole())) { return redirect:/admin/index; } else if (teacher.equals(user.getRole())) { return redirect:/teacher/index; } return redirect:/student/index; } }登录成功后把完整user对象放进session后续拦截器取角色就非常方便。用户表里role字段我用了字符串而不是数字牺牲了一点点存储空间换来了极高的可读性。登录失败统一返回登录页并携带错误消息不在页面上暴露过多的细节比如账号不存在和密码错误我合并成了同一句用户名或密码错误避免被用来探测账号是否存在。4.2 学生提交评教的完整链路提交评教是整个系统里链路最长、最容易出问题的一个功能。前端是一个列表每个待评教项打开一个弹窗或新页面展示当前教师对应的所有指标学生逐项打分后提交。后端接收的是一个指标得分数组而不是单条记录。前端提交的数据结构我定义成这样{ studentId: 1001, teacherId: 2003, courseId: 3005, semesterId: 1, scores: [ {indicatorId: 1, score: 92}, {indicatorId: 2, score: 85}, {indicatorId: 3, score: 96} ] }Service层的处理逻辑Service public class EvalServiceImpl implements EvalService { Transactional(rollbackFor Exception.class) Override public void submitEvaluation(EvalSubmitDTO dto) { // 1. 校验学期是否处于开放状态 Semester semester semesterMapper.selectById(dto.getSemesterId()); if (semester null || !open.equals(semester.getStatus())) { throw new BusinessException(当前学期不在评教开放时间内); } // 2. 校验该学生是否已评过 int count evalRecordMapper.countByUnique( dto.getStudentId(), dto.getTeacherId(), dto.getCourseId(), dto.getSemesterId()); if (count 0) { throw new BusinessException(您已经评价过该教师请勿重复提交); } // 3. 逐条插入指标得分 for (ScoreItem item : dto.getScores()) { EvalRecord record new EvalRecord(); record.setStudentId(dto.getStudentId()); record.setTeacherId(dto.getTeacherId()); record.setCourseId(dto.getCourseId()); record.setSemesterId(dto.getSemesterId()); record.setIndicatorId(item.getIndicatorId()); record.setScore(item.getScore()); evalRecordMapper.insert(record); } } }这个方法的重点是Transactional(rollbackFor Exception.class)。默认情况下Spring事务只在RuntimeException时才回滚如果你在方法里抛的是自定义的业务异常且没有继承RuntimeException事务不会回滚半截插入的数据就会留在库里。我一开始就踩过这个坑所以后来自定义异常一律继承RuntimeException或者显式声明rollbackFor。事务粒度上一次提交的所有指标得分应该是同生共死的——要么全部插入成功要么全部回滚。所以整个批量插入必须在一个事务方法里完成而不是拆成多次调用。4.3 统计报表的SQL与接口设计统计报表是管理员的面子工程也是查询性能最容易翻车的地方。最常规的统计有四种每位教师的平均分按学期每个指标的细项平均分按学期、按学院教师综合排名加权总分排序各学院评教参与率。这些统计如果全部在Java代码里做循环查询N1问题会非常明显。我的做法是能一条SQL算完的就不查两次。比如教师综合排名SELECT t.id, t.teacher_name, SUM(e.score * i.weight) AS weighted_total, AVG(e.score) AS avg_score, COUNT(DISTINCT e.student_id) AS eval_students FROM t_eval_record e JOIN t_teacher t ON e.teacher_id t.id JOIN t_indicator i ON e.indicator_id i.id WHERE e.semester_id #{semesterId} GROUP BY t.id, t.teacher_name ORDER BY weighted_total DESC一次关联查询就把加权总分、平均分、参评人数全部算出来之后在Java层做分页展示或者导出Excel都方便。对于参评率统计需要先拿到应该参评的人数和实际参评的人数前者由t_teaching任课关系表里按班级关联出来的总人数决定后者用真实插入的评教记录去重统计两边一对比就是参与率。需要说明的一点是统计接口返回的数据量如果很大不要一次全部渲染到页面上。教师数量超过几百时表格加载就会明显变慢。我给报表接口统一加了PageHelper分页每页20条页面用局部刷新渲染体验好了很多。5. 上线前后踩过的坑这些问题都是隐藏的扣分项5.1 重复评教问题比你想象的更容易发生第一个坑就是前面说的重复评教。我在本地测试时一切正常但做了并发模拟之后发现两个请求同时进来Java代码里的countByUnique都返回0然后两条记录都插入成功了。数据库唯一索引是我最后一道防线没有它数据直接就脏了。这个问题给我的教训是凡是唯一性约束的规则数据库层面必须兜底不能只依赖应用层。SSM项目里很多人习惯性把校验逻辑堆在Service里觉得够用就行但一旦部署到真实环境、并发量稍大这种够用就会变成事故。5.2 统计查询性能没加索引的JOIN是灾难统计报表涉及多表JOIN数据量不大时感觉不出来一旦评教记录到了几十万行查询时间会从几百毫秒飙到好几秒。排查之后发现问题出在t_eval_record表上除了唯一索引之外没有针对查询条件的索引。-- 统计查询最常用的过滤条件学期 教师 ALTER TABLE t_eval_record ADD INDEX idx_semester_teacher (semester_id, teacher_id); -- 学生查询自己的历史记录 ALTER TABLE t_eval_record ADD INDEX idx_student (student_id);加完之后同样的统计查询耗时从2秒多降到200毫秒左右。深入分析执行计划你还会发现MySQL的优化器在字段区分度不高时可能会放弃索引所以复合索引字段的顺序也很重要——高区分度字段放前面比如把semester_id放teacher_id前面是因为一个学期的数据范围本身就比分教师的范围更清晰。5.3 事务失效的三个常见原因评教系统涉及多表写入事务用得多自然也踩过不少事务失效的坑。复盘下来有三个原因最常见方法内部自调用同一个类里一个方法调用另一个带Transactional的方法事务注解不生效因为走的是this调用而不是代理对象。解决办法是拆到不同的Service类或者通过AopContext拿到代理对象。异常被吞掉Service方法内部try-catch了异常但没抛出事务判断不了需要回滚。正确做法是catch之后记录日志并重新抛出或者让异常直接向外传播。rollbackFor没指定自定义的业务异常如果不继承RuntimeException默认是不回滚的。最稳妥的做法是自定义异常统一继承RuntimeException并在Transactional里写清楚rollbackFor Exception.class。这三个坑在评教系统里几乎全被我踩了一遍最后整理成了一份事务自查清单以后做其他项目也直接照用。5.4 数据库连接池参数配置不当导致的连接耗尽我遇到过系统跑了一段时间后突然卡死所有请求全部超时。看Druid监控面板发现连接池的activeCount徘徊在最大值而且连接数一直降不下来。原因有两个一是连接池maxActive设得太小并发高峰期连接不够用请求排队等待二是代码里存在连接未归还的情况。排查后确认是某个Service方法里手动获取了Connection但忘了close。后来我强制要求所有数据库操作一律走MyBatis的Mapper接口不允许在Service层手动创建Connection从根源上杜绝资源泄漏。连接池的合理参数我以当前这个项目的经验给出一组参考值参数参考值说明initialSize2启动时建立的最小连接数minIdle2空闲时保留的最小连接数maxActive20最大活跃连接数maxWait60000获取连接的最大等待时间毫秒timeBetweenEvictionRunsMillis60000空闲连接检测周期minEvictableIdleTimeMillis300000连接最小空闲时间毫秒参数不是死的要根据实际部署环境动态调。但有一条原则很明确宁愿让少量请求排队等待也别把maxActive调得过大压垮数据库。连接池是缓冲不是并发加速器。5.5 前端细节对系统口碑的影响最后说一个容易被忽略的层面评教系统的使用者很多是学生他们不会关心你的架构有多好只关心卡不卡、顺不顺、会不会突然报错。前端我做了三件小事效果非常明显第一提交评教后立即把按钮设为disabled并显示提交中从交互层面减少重复点击第二表单离开页面前提示评教未完成降低学生误关页面的概率第三所有操作成功统一弹出轻提示而不是跳转新页面保持用户的操作节奏。这些小改动加起来的维护成本很低但用户的投诉量会明显减少。对评教系统这种周期性使用的系统来说用户体验就是最大的隐藏需求。6. 一套评教系统做完之后还能往哪些方向扩展SSM273跑通之后如果想继续往深做有几个方向我认为性价比很高。第一个是评价维度的细粒度化。目前评价的主体是教师事务边界是一门课程和一个学期。但在真实教务场景里同一门课程可能有多个教学班同一个教师给不同班级上课学生感受差异很大。可以引入教学班概念把评教数据细化到班级维度统计报表也支持按班级下钻查看。第二个是评教数据的预警机制。当某个教师的得分连续两个学期下滑或者某一项指标得分异常偏低系统自动推送预警给教务处。这个功能不需要太复杂定时任务里跑一遍统计SQL命中阈值就生成一条预警记录即可。第三个是移动端适配。评教系统的使用场景集中在学期末大部分学生用手机访问。如果部署在公网建议直接用响应式布局的后台模板如果学校有统一门户可以考虑把评教入口做成轻量H5页面省去安装App的成本。以上三个方向第一个改的是数据模型第二个加的是定时任务第三个动的是前端工程正好覆盖了Java后端、任务调度、前端适配三个不同的技能点。按照自己的职业方向选一个深入做下去收获会比重复堆CRUD大得多。评教系统做完之后我自己最大的体会是SSM项目从来不是靠框架本身取胜而是靠对业务规则的拆解和对细节的把控。同样的代码框架有的人做完只是一个CRUD模板有的人做完是一套能经得起真实使用的系统差别全在这些看不见的地方。如果你也正在做类似的项目建议优先把权限边界、唯一性约束和统计口径这三件事想清楚剩下的功能其实都是时间问题。