企业人事管理系统SSM框架JavaWeb源码实战解析

简介企业人事管理系统是一套基于SSM框架与JSP技术的JavaWeb毕业设计/课程设计资源面向计算机专业学生覆盖管理员、部门经理、员工三类角色实现了员工管理、部门信息维护、考勤、签到、请假申请、工资查询等核心功能可直接作为课设或毕设的完整项目方案。资源包内含6个文件包括源码压缩包、MySQL数据库脚本sql、需求/开发文档docx及答辩PPTpptx压缩包整体约25.46MB结构清晰、便于按模块查阅。目前已有61人学习下载适合需要快速上手SSM项目开发、完成毕设系统搭建的用户。资料已调试无误附有运行环境与部署视频教程按步骤导入即可运行同时提供论文与PPT帮助使用者快速理解系统设计思路并顺利完成答辩与文档撰写。1. 企业人事管理系统为什么绕不开 SSM 这套 javaweb 组合企业人事管理系统在毕设题目里出现频率极高业务对象明确字段量又足够让数据库设计环节不显得单薄。加上ssm框架和javaweb两个标签叠加技术栈基本被锁成标准答案——Spring 管业务对象、SpringMVC 接请求、MyBatis 写 SQL三层各司其职答辩时每一层都有话可讲。这条链路看着简单坑却不少Interceptor 不生效、Mapper 绑定失败、Tomcat 版本不兼容都是高频翻车点。这里按先理清选型、再搭工程骨架、然后设计数据库、最后落到联调与部署的顺序把这套方案的关键参数和排查思路过一遍。源码里最容易改坏、也最容易讲清楚的部分集中在第 4、5 章展开。适合正在赶交付的学生也适合要快速接手 javaweb 项目的开发者。2. SSM 框架在人事系统里的分工逻辑与工程骨架搭建2.1 为什么毕设场景仍选 SSM 而不是 Spring Boot先回答所有人都会问的问题既然 Spring Boot 那么成熟为什么这套 javaweb 方案还在用 SSM原因在课程设计场景里很现实——不少院校的 JavaWeb 课程大纲还停留在 SSM JSP 阶段出题和答辩评委对这套结构的提问点非常固定IOC 容器怎么管理对象、AOP 事务切在哪一层、DispatcherServlet 如何转发、Mapper 接口怎么定位 SQL。用 SSM 写出来每一层都能对应到课程知识点这比 Spring Boot 一把梭更容易讲深讲透。另一个原因和执行环境有关。毕设演示机上的 JDK、Tomcat 版本往往比较旧SSM 打的 war 包对容器的兼容性比 Spring Boot 内嵌容器的可执行 jar 更宽松部署失败率反而低。从职责划分上看SSM 的三层边界非常干净Spring 负责对象的创建和依赖注入。Service、DAO、Controller 全部注册进容器不在业务代码里手动 new 依赖对象。SpringMVC 负责 HTTP 请求的接收与分发。前端提交的参数先到 DispatcherServlet再按 RequestMapping 映射到具体方法。MyBatis 负责 SQL 与 Java 对象的转换。查询结果集按 ResultMap 或自动驼峰映射封装成实体SQL 写在 Mapper XML 里与 Java 代码分离。映射到人事系统里就是一条清晰的调用链浏览器发起查询员工列表请求EmployeeController 接收参数EmployeeService 做权限与业务校验EmployeeMapper 的 XML 里执行 SELECT。任何一层被问到这行代码在做什么都能顺着链路答出来这是答辩时最加分的部分。这套工程骨架最终交付出去就是标题里源码目录的核心内容后续论文的架构图也按这个分层画。2.2 Maven 工程目录与三层分包规范用 Maven 建工程时目录结构决定了一件事包扫描不到、XML 资源没打进去这类代码看起没问题但跑不起来的报错大部分能在目录层避免。人事系统常见的分包如下hrms ├── pom.xml ├── src/main/java │ └── com/example/hrms │ ├── controller # EmployeeController, DeptController, UserController │ ├── service # EmployeeService 接口及其 impl 实现 │ ├── dao # EmployeeMapper, DeptMapper 接口 │ ├── entity # Employee, Dept, Attendance, Salary, AdminUser │ ├── interceptor # LoginInterceptor │ └── common # Result, PageResult 等公共类 ├── src/main/resources │ ├── jdbc.properties │ ├── applicationContext.xml │ ├── springmvc-config.xml │ └── mapper # EmployeeMapper.xml, DeptMapper.xml └── src/main/webapp ├── WEB-INF │ ├── web.xml │ └── views # login.jsp, employee_list.jsp 等页面 └── static # css, js, images这里有两个容易被忽略的坑。第一个是 mapper 目录下的 XML 默认不会被 Maven 打包进 war需要在 pom.xml 的 build 节点里显式声明 resources 目录否则运行时直接报org.apache.ibatis.binding.BindingException而 IDEA 里本地跑着却正常非常迷惑。第二个是包名建议写成com.公司名.项目名这种三级以上结构一级包名在组件扫描时偶尔会扫出多余的同名 Bean虽然不常见但没必要在赶进度时赌运气。2.3 三个配置文件的职责与必配参数SSM 工程的主配置分三块web.xml 管 Servlet 注册applicationContext.xml 管 Spring 根容器数据源、事务、Service、Mapperspringmvc-config.xml 管 Web 层Controller 扫描、视图解析、静态资源放行。三层容器关系是嵌套的SpringMVC 容器是 Spring 根容器的子容器Controller 里能用 Autowired 拿到父容器的 Service反过来不行。配置文件管理范围最容易漏配的参数web.xmlServlet、过滤器、监听器CharacterEncodingFilter 的 url-patternapplicationContext.xml数据源、事务、Service、MappermapperLocations 指向的目录springmvc-config.xmlController、视图解析、拦截器mvc:default-servlet-handlerweb.xml 里的关键配置是 DispatcherServlet 与字符编码过滤器filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping servlet servlet-namespringmvc/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:springmvc-config.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namespringmvc/servlet-name url-pattern//url-pattern /servlet-mapping说明CharacterEncodingFilter 必须声明在其他过滤器之前且 url-pattern 配成/*表示所有路径都走编码过滤否则 POST 提交的中文在进入 Controller 之前就乱码了。DispatcherServlet 的 url-pattern 配成/表示所有请求都交给 SpringMVC这要求 Web 层配置里必须放行 JSP 与静态资源否则浏览器加载 css、js 的请求也会被当成 Controller 请求处理页面样式全部丢失。springmvc-config.xml 里的四个必配项是组件扫描、注解驱动、视图解析器和静态资源放行context:component-scan base-packagecom.example.hrms.controller/ mvc:annotation-driven/ bean classorg.springframework.web.servlet.view.InternalResourceViewResolver property nameprefix value/WEB-INF/views// property namesuffix value.jsp/ /bean mvc:default-servlet-handler/视图解析器的 prefix/suffix 决定了 Controller 里return employee_list拼接出的最终路径是/WEB-INF/views/employee_list.jsp。把 JSP 放在 WEB-INF 下有个额外好处浏览器没法直接用 URL 访问页面未登录用户只能通过 Controller 转发进入权限控制少一个入口要堵。applicationContext.xml 负责数据源、SqlSessionFactory、Mapper 扫描和事务管理器context:property-placeholder locationclasspath:jdbc.properties/ bean iddataSource classorg.springframework.jdbc.datasource.DriverManagerDataSource property namedriverClassName value${jdbc.driver}/ property nameurl value${jdbc.url}/ property nameusername value${jdbc.username}/ property namepassword value${jdbc.password}/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.example.hrms.dao/ /bean tx:annotation-driven transaction-managerdataSourceTransactionManager/注意 SqlSessionFactoryBean 的 mapperLocations 与 MapperScannerConfigurer 的 basePackage 是配对出现的。前者告诉 MyBatis 去哪找 XML后者告诉容器哪个包下的接口需要生成代理实现。两者缺一报错都是Invalid bound statement (not found)或BindingException但排查方向完全不同——先看 mapperLocations 能否匹配到文件再看接口包名是否被 basePackage 覆盖。3. 人事系统数据库设计五张表的字段取舍与关联方式3.1 从业务对象到表结构的设计思路人事管理系统的核心业务对象有三个部门、员工、登录账号考勤和薪资本质上是员工的从属数据。毕设场景把表数量控制在 5 张左右最合适——太少撑不起论文里数据库设计章节的篇幅太多容易在答辩时被追问字段细节而答不上来。常见五张表的分工如下表名存储内容关键字段关联方向dept部门与负责人id, dept_name, manageremployee.dept_id 指向 dept.idemployee员工档案id, emp_no, name, gender, phone, dept_id, position, hire_date多对一关联 deptattendance每日考勤状态id, emp_id, work_date, status多对一关联 employeesalary月度薪资明细id, emp_id, base_salary, bonus, month多对一关联 employeeadmin_user系统登录账号id, username, password, role与 employee 逻辑独立设计时有一条容易被忽略的原则员工编号 emp_no 用业务编号而不是自增主键。自增 id 在列表页和导出 Excel 时没有业务含义而 emp_no 可以由年份 部门序号 流水号拼成例如 2025001展示在页面上更像真实的企业数据。另一个决策点是 admin_user 与 employee 的关系常见的做法是两者独立登录账号表只管认证员工表只管人事档案避免先有账号还是先有员工的死循环。答辩时被问到为什么不做成一张表这个拆分理由可以答得很清楚。3.2 建库建表 SQL 与初始化数据脚本数据库一般选 MySQL 5.7 或 8.0字符集统一 utf8mb4避免生僻字姓名保存失败。建库建表脚本如下CREATE DATABASE IF NOT EXISTS hrms DEFAULT CHARACTER SET utf8mb4; USE hrms; CREATE TABLE dept ( id INT PRIMARY KEY AUTO_INCREMENT, dept_name VARCHAR(50) NOT NULL UNIQUE, manager VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE employee ( id INT PRIMARY KEY AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(20) NOT NULL, gender CHAR(1) DEFAULT 男, phone VARCHAR(11), dept_id INT, position VARCHAR(50), hire_date DATE, CONSTRAINT fk_emp_dept FOREIGN KEY (dept_id) REFERENCES dept(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE attendance ( id INT PRIMARY KEY AUTO_INCREMENT, emp_id INT NOT NULL, work_date DATE NOT NULL, status TINYINT DEFAULT 0 COMMENT 0正常 1迟到 2缺勤, CONSTRAINT fk_att_emp FOREIGN KEY (emp_id) REFERENCES employee(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE salary ( id INT PRIMARY KEY AUTO_INCREMENT, emp_id INT NOT NULL, base_salary DECIMAL(10,2) NOT NULL, bonus DECIMAL(10,2) DEFAULT 0.00, month VARCHAR(7) NOT NULL, CONSTRAINT fk_sal_emp FOREIGN KEY (emp_id) REFERENCES employee(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE admin_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(30) NOT NULL UNIQUE, password CHAR(32) NOT NULL, role VARCHAR(10) DEFAULT USER ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;参数说明emp_no 加 UNIQUE防止同一员工编号重复录入dept_id 建外键约束保证删除部门时不会留下悬空的员工记录。engine 指定 InnoDB 是为了让外键和事务生效MyISAM 不支持外键这点在论文里通常要写一句。salary 的 base_salary 用 DECIMAL(10,2) 而不是 FLOAT浮点类型做金额计算会有精度误差工资计算场景必须用定点数。初始数据要预置得足够像真的答辩演示时才有效果INSERT INTO dept (dept_name, manager) VALUES (技术部, 张伟), (人事部, 李娜), (财务部, 王强); INSERT INTO employee (emp_no, name, gender, phone, dept_id, position, hire_date) VALUES (2025001, 赵敏, 女, 13800001111, 1, Java工程师, 2025-03-01), (2025002, 陈杰, 男, 13800002222, 2, 招聘专员, 2025-03-15), (2025003, 孙丽, 女, 13800003333, 3, 会计, 2025-04-01); INSERT INTO admin_user (username, password, role) VALUES (admin, e10adc3949ba59abbe56e057f20f883e, ADMIN);admin_user 里的 password 字段存的是 MD5 值明文是 123456。这里的实践建议是毕设项目用 MD5 加盐或 SHA-256 均可但论文里千万不要写密码明文存储这句话在答辩时会被当成安全短板追问。演示时如果不想暴露 root 密码可以单独建一个 hrms 账号并只授这个库的权限脚本截图会干净很多。3.3 关联查询的 JOIN 写法与空值处理员工列表页几乎一定需要显示部门名称而部门名称在 dept 表里。常见做法是 LEFT JOIN 而不是子查询SELECT e.id, e.emp_no, e.name, e.gender, e.phone, d.dept_name, e.position, e.hire_date FROM employee e LEFT JOIN dept d ON e.dept_id d.id WHERE e.name LIKE CONCAT(%, #{keyword}, %) ORDER BY e.id DESC;用 LEFT JOIN 而不是 INNER JOIN 的理由是即使某个员工的 dept_id 为空例如离职归档前部门已删除员工记录仍要显示出来。LEFT JOIN 以左表 employee 为基准右表没有匹配时部门名字段返回 NULL这条记录不会被过滤掉。实际开发里更常见的是多条件组合查询WHERE 部分要交给 MyBatis 的动态标签处理避免 keyword 为空时拼出WHERE e.name LIKE %%这种全表扫描写法具体配置在第 4 章给出。顺手提一个常被问到的写法WHERE 11的作用是保证动态拼接 SQL 时即使所有条件都不命中语句也不会以 WHERE 裸结尾而语法报错。但 MyBatis 提供了where标签它会自动处理第一个条件前的 AND 或 OR比11可读性更好推荐用标签而不是写死条件。4. 打通人事系统的核心链路登录拦截、事务与动态 SQL4.1 登录拦截器的注册与放行路径人事管理系统必须解决权限控制。最轻量的方案是 HandlerInterceptor 加 Session 存储登录态。自定义拦截器实现 HandlerInterceptor 接口在 preHandle 里判断public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); Object loginUser session.getAttribute(loginUser); if (loginUser null) { response.sendRedirect(request.getContextPath() /login); return false; } return true; } }逻辑说明preHandle 的返回值决定请求是否继续向下执行。返回 false 表示拦截直接重定向到登录页返回 true 放行。这里最常踩的坑是 key 不一致——登录时存的是user拦截器里取loginUser取出来永远是 null表现为登录成功了但马上被弹回登录页这类问题在赶进度时最耗时间。建议把 Session 的 key 定义成常量类统一管理一处定义、两处使用。拦截器注册在 springmvc-config.xml 中拦截与放行路径分开配mvc:interceptors mvc:interceptor mvc:mapping path/**/ mvc:exclude-mapping path/login/ mvc:exclude-mapping path/static/**/ bean classcom.example.hrms.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptors注意/**与/的区别/**匹配所有层级路径既包含/employee/list也包含/static/css/style.css。所以静态资源必须显式 exclude否则登录页加载不出样式。另一个容易被漏掉的是/logout路径——如果退出操作走的是 Controller也要在 exclude 里放行或者干脆让拦截器对已登录用户放行由 Controller 自己清 Session。4.2 Controller 层的参数绑定与视图返回员工列表页的 Controller 是这套系统里最典型的写法Controller RequestMapping(/employee) public class EmployeeController { Autowired private EmployeeService employeeService; RequestMapping(/list) public String list(RequestParam(value keyword, required false) String keyword, RequestParam(value pageNum, defaultValue 1) Integer pageNum, Model model) { PageResult pageResult employeeService.pageList(keyword, pageNum, 10); model.addAttribute(pageResult, pageResult); return employee_list; } }参数说明RequestParam的 required 默认是 true前端不传 keyword 时会直接抛 400 错误写成required false才能让不带参数的访问成为合法请求。pageNum 设置 defaultValue是为了避免首次进入列表页时拿到 null导致后续 LIMIT 偏移量计算出现空指针。返回的字符串会被 InternalResourceViewResolver 拼成 JSP 路径如果视图解析器的 prefix/suffix 与目录结构对不上页面 404 但控制台没有异常这时第一反应应该是回头查视图解析器配置而不是代码。4.3 Service 层事务边界的三个关键参数Service 层的方法一般加 Transactional。人事系统里典型的写操作是入职登记插入员工记录、生成登录账号、初始化一条考勤记录三步要么全部成功要么全部回滚Service public class EmployeeServiceImpl implements EmployeeService { Transactional(rollbackFor Exception.class) Override public void addEmployee(Employee employee) { employeeDao.insert(employee); adminUserDao.insert(buildUser(employee)); attendanceDao.initRecord(employee.getId()); } }需要关注的参数是 rollbackFor。Spring 默认只对 RuntimeException 和 Error 回滚对受检异常不生效。业务代码里如果 throw 的是 Exception 及其子类不加 rollbackFor 会导致三步只写了两步数据半截留在库里演示到这一步时非常尴尬。第二个参数是 isolation默认沿用数据库的 REPEATABLE READ一般不用改但论文事务章节写一句采用数据库默认隔离级别可以对应上知识点。第三个容易被忽略的是 self-invocation 问题同类内部方法直接调用 this.addEmployee()Transactional 会失效因为它走的是代理对象——跨类注入调用才是正确姿势。4.4 MyBatis 动态 SQL 与手写分页的取舍列表页的查询条件通常不止关键词还有部门和入职时间范围这时用多条件动态拼接select idselectEmployeeList resultTypecom.example.hrms.entity.EmployeeVO SELECT e.id, e.emp_no, e.name, e.gender, e.phone, d.dept_name, e.position, e.hire_date FROM employee e LEFT JOIN dept d ON e.dept_id d.id where if testkeyword ! null and keyword ! AND (e.name LIKE CONCAT(%, #{keyword}, %) OR e.emp_no LIKE CONCAT(%, #{keyword}, %)) /if if testdeptId ! null AND e.dept_id #{deptId} /if /where ORDER BY e.id DESC LIMIT #{offset}, #{pageSize} /select参数说明where标签自动处理第一个条件前的 AND比手写WHERE 11更规范。test 里的空判断必须写! null and ! 只写一个会在空字符串场景下拼出多余的 AND。CONCAT 是 MySQL 的字符串拼接函数跨数据库时可移植性更好。#{keyword}是预编译占位符${}是字符串直接拼接——搜索词必须用#{}如果用${}等于把用户输入拼进 SQL存在注入风险论文安全章节值得单独写一段论证。分页部分推荐手写 LIMIT。虽然 PageHelper 插件配置更省事但手写 LIMIT 反而更好答辩分页方案额外代码量答辩关注点手写 LIMIT offset, pageSize一个 COUNT 加一个列表查询能讲清 offset 与 pageSize 的换算关系PageHelper.startPage一行代码容易被追问插件拦截 SQL 的内部原理配合分页的 COUNT 查询要与列表查询共用同一段where条件实践做法是用sql标签把条件段抽出来两处 include避免条件写两遍后出现总数和列表对不上的经典 bug。offset 的计算公式是 (pageNum - 1) * pageSize这个公式建议直接写在 Service 里而不是 Controller 里保证任何入口调用的分页逻辑一致。5. 人事系统部署 Tomcat 的版本坑与答辩演示的验证技巧5.1 版本组合与三个高频报错SSM 项目最怕版本互不兼容。常见组合和典型报错如下组件推荐版本典型报错JDK1.8高版本 JDK 编出的 class 部署到老 Tomcat 报 UnsupportedClassVersionErrorTomcat8.5 或 9.0注解扫描失败或 EL 表达式不生效MySQL5.7 或 8.0驱动类名不同导致 ClassNotFoundExceptionMaven3.6.x本地运行正常导出的 war 缺依赖跑不起来三个高频报错直接给排查结论ClassNotFoundException: com.mysql.jdbc.Driver说明驱动与数据库版本不对应MySQL 8.x 必须用com.mysql.cj.jdbc.Driver且 url 要追加useSSLfalseserverTimezoneAsia/Shanghai。Invalid bound statement (not found)先解压 war 包确认 mapper XML 是否在 classes 目录里别急着改 Java 代码。页面 404 且控制台无异常优先检查 Web 视图解析器的 prefix 是否写错了目录名。这些坑在论文的系统测试章节里可以对应成三条问题记录属于实打实的排错素材。5.2 答辩演示前必做的三件事第一预置数据要够多。employee 表至少 20 条以上覆盖不同部门、不同职位分页和模糊查询的演示效果才真实。第二演示当天用无痕窗口打开系统避免上一次 Session 残留干扰。第三MySQL 和 Tomcat 都装在本机演示环境不依赖任何远端服务现场网络波动不影响流程。配套的论文与 PPT 结构建议这样对应论文的技术选型章节直接引用第 2 章的三层分工数据库设计章节对应第 3 章表结构系统实现章节放第 4 章的拦截器、事务和动态 SQL 三个片段PPT 按背景—技术栈—数据库设计—功能演示—测试与总结五页走页数控制在 12 页以内把第 4 章的环境变量配置错误作为技术难点提一句比单纯列功能点更有说服力。5.3 一个可以当场验证的技巧让日志输出 SQL 参数给 MyBatis 打开标准输出日志控制台会打印预编译 SQL 和实际传入参数排查参数绑定问题非常高效。在 mybatis-config.xml 的 settings 节点加settings setting namelogImpl valueSTDOUT_LOGGING/ /settings开启后控制台会输出两行一行是 Preparing: SELECT ...一行是 Parameters: 赵(String)。答辩前故意在搜索框输入一个%或单引号观察日志里参数是否被 MyBatis 当作值处理而不是拼进 SQL这一条可以直接演示给评委看——为什么不能用字符串拼接 SQL从概念变成可见的日志证据。再进一步把这个日志行为写进论文的测试章节配一张控制台截图属于不需要额外工作量就能加分的素材比把项目代码背下来管用得多。本文还有配套的精品资源点击获取