Java-Spring入门指南（二十二）SSM整合前置基础

---

前言

• 在前文的学习中，我们已经掌握了Spring的IOC/DI核心思想、SpringMVC的请求处理与视图渲染（Thymeleaf），也通过MyBatis专栏学习了数据持久层的操作逻辑。
• 但实际开发中，单独使用这三个框架会面临“配置零散、层间衔接繁琐”的问题——比如Spring管理的Service无法直接调用MyBatis的Mapper，SpringMVC的Controller要手动传递参数到Service，各框架的配置文件相互独立难以维护。

• SSM（Spring + SpringMVC + MyBatis）整合的核心，就是将这三个框架“拧成一股绳”：让Spring成为“总指挥”，统一管理所有组件（Service、Mapper、Controller）；让SpringMVC专注“接收请求、返回响应”；让MyBatis专注“操作数据库”，三者各司其职又无缝衔接，最终形成一套高效、易维护的企业级开发架构。

• 本文作为SSM整合的“前置铺垫”，不会直接写代码，而是先理清“SSM是什么、为什么要整合、整合要解决什么问题”，为下一篇的“手把手代码整合”打好基础。

我的个人主页，欢迎来阅读我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的Java-Spring入门指南知识文章专栏
欢迎来阅读指出不足
https://blog.csdn.net/2402_83322742/category_13040333.html?spm=1001.2014.3001.5482
MyBatis中文官方网站
https://mybatis.net.cn/getting-started.html
我的MyBatis实战指南专栏
https://blog.csdn.net/2402_83322742/category_12969707.html?spm=1001.2014.3001.5482

---

一、SSM是什么？三个框架各管什么？

SSM不是一个“新框架”，而是Spring、SpringMVC、MyBatis三个框架的组合，它们在架构中分别承担“不同层级的职责”，就像一个公司里的“管理层、业务接待层、执行层”，分工明确才能高效运转。

框架	核心定位	负责层级	核心职责（在SSM中）	关键技术点（需掌握）
Spring	容器与整合核心	业务逻辑层（Service）+ 全局管理	1. 用IOC容器统一管理所有组件（Service、Mapper、Controller）； 2. 用DI实现组件间依赖注入（如Service注入Mapper）； 3. 提供事务管理（确保数据库操作原子性）	IOC/DI、注解（@Component/@Service）、事务管理
SpringMVC	请求处理与视图交互	表现层（Controller）	1. 接收前端请求（如GET/POST）； 2. 调用Service层处理业务逻辑； 3. 返回响应（JSON或Thymeleaf视图）； 4. 处理参数绑定（@RequestParam/@RequestBody）	@Controller、@RequestMapping、参数绑定、视图解析器
MyBatis	数据持久层（操作数据库）	持久层（Mapper）	1. 编写SQL语句（XML或注解）； 2. 实现数据库CRUD操作； 3. 完成Java对象与数据库表的映射（ResultMap）； 4. 管理数据库连接（依赖Spring配置）	Mapper接口、SQL映射文件、ResultMap、分页

简单来说：

• 前端发起请求 → SpringMVC（Controller） 接收 → 调用 Spring（Service） 处理业务 → MyBatis（Mapper） 操作数据库 → 结果逐层返回 → 前端显示。
• 而“整合”的本质，就是让这个“逐层调用”的过程无需手动编写衔接代码（比如不用手动new Service、不用手动获取Mapper），全由Spring自动管理。

二、为什么要整合SSM？

• “我已经会单独用Spring、SpringMVC、MyBatis了，为什么还要费劲整合？
• ” 答案很简单——单独使用时，层间衔接的“手动操作”会让代码冗余、易出错、难维护，尤其是在中大型项目中。

我们通过“用户查询”的场景，对比“单独用”和“整合后”的差异，直观感受整合的价值：

2.1 单独用的痛点

假设要实现“前端发起请求→查询用户信息→返回页面”，单独使用三个框架时，需要手动做以下衔接：

1. MyBatis层：手动获取SqlSession，再获取Mapper，才能操作数据库

   // 单独用MyBatis：每次查数据库都要写这段代码，冗余！
   InputStream in = Resources.getResourceAsStream("mybatis-config.xml");
   SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(in);
   SqlSession session = factory.openSession();
   UserMapper userMapper = session.getMapper(UserMapper.class);
   User user = userMapper.findById(1); // 查用户
   session.close(); // 手动关闭，容易忘！
   

2. Spring层：Service要手动调用MyBatis的Mapper，无法依赖注入

   @Service
   public class UserService {// 单独用：Service要手动创建Mapper，不能自动注入，耦合度高！public User findUserById(int id) {// 重复写MyBatis的初始化代码...SqlSession session = ...;UserMapper mapper = session.getMapper(UserMapper.class);return mapper.findById(id);}
   }
   

3. SpringMVC层：Controller要手动获取Service，无法自动注入

   @Controller
   public class UserController {// 单独用：Controller要手动new Service，不灵活！private UserService userService = new UserService(); // 硬编码，无法替换实现类@RequestMapping("/user/{id}")public String findUser(@PathVariable int id, Model model) {User user = userService.findUserById(id);model.addAttribute("user", user);return "user";}
   }
   

4. 配置文件混乱：每个框架都有独立配置文件，维护成本高

   • MyBatis需要mybatis-config.xml（配置数据源、Mapper路径）；
   • Spring需要applicationContext.xml（配置Service、事务）；
   • SpringMVC需要springmvc.xml（配置Controller、视图解析器）；
   • 三个文件各自独立，修改数据源时要同时改MyBatis和Spring的配置，容易出错。

2.2 整合后的优势

整合后，上述“手动操作”全被Spring的自动管理替代，代码和配置大幅简化：

1. 依赖注入：无需手动new组件

   • Service中直接用@Autowired注入Mapper；
   • Controller中直接用@Autowired注入Service；
     代码示例：

   // 整合后：Service注入Mapper（Spring自动从IOC容器获取）
   @Service
   public class UserService {@Autowired // 自动注入MyBatis的Mapper，无需手动创建！private UserMapper userMapper;public User findUserById(int id) {return userMapper.findById(id); // 直接调用，无需MyBatis初始化代码}
   }// 整合后：Controller注入Service
   @Controller
   public class UserController {@Autowired // 自动注入Service，无需手动new！private UserService userService;// 后续逻辑不变，代码更简洁
   }
   

2. 配置统一：数据源等配置集中管理
   整合后，数据库连接（数据源）只需在Spring的配置文件中配置一次，MyBatis不再需要单独的mybatis-config.xml，所有框架共享Spring的配置，减少重复配置。

3. 事务统一管理
   单独用MyBatis时，事务需要手动控制（session.commit()）；整合后，只需在Spring中通过注解@Transactional，就能为Service方法添加事务，确保数据库操作要么全成功、要么全失败。

4. 开发效率提升
   开发者无需关注“组件如何创建、如何衔接”，只需专注“业务逻辑”（如Service层写业务、Mapper层写SQL），大幅减少冗余代码，降低出错概率。

三、SSM整合要“整合什么”？

明确了“为什么整合”后，我们再聚焦“整合的具体内容”——其实就是解决三个核心问题，这也是下一篇代码整合时的重点：

1. 整合组件管理：让Spring接管MyBatis的Mapper

• 问题：单独用MyBatis时，Mapper接口的实现类由MyBatis动态生成（通过SqlSession），Spring无法管理；
• 解决：通过MyBatis-Spring依赖（中间件），让Spring能识别MyBatis的Mapper，将其作为Bean放入IOC容器，从而实现@Autowired注入。

2. 整合数据源：让MyBatis使用Spring配置的数据库连接

• 问题：单独用MyBatis时，数据源配置在mybatis-config.xml中；
• 解决：在Spring配置文件中配置“数据源”（如Druid连接池），让MyBatis直接使用Spring的数据源，统一管理数据库连接，避免重复配置。

3. 整合事务：让Spring为MyBatis的操作添加事务

• 问题：MyBatis的事务默认手动控制，且无法跨Mapper操作；
• 解决：在Spring中配置“事务管理器”，通过@Transactional注解为Service方法添加事务，确保多个Mapper操作（如新增用户+新增订单）要么全成功、要么全失败。

4. 整合SpringMVC与Spring：让Controller能调用Service

• 问题：单独用SpringMVC时，Controller由SpringMVC的容器管理，Service由Spring的容器管理，两者无法直接通信；
• 解决：让SpringMVC的容器“继承”Spring的容器，确保Controller能从Spring容器中获取Service实例，实现跨容器调用。

以上便是SSM整合前置基础
下一篇我们开始详细讲解利用IDEA实现Spring + SpringMVC + MyBatis整合

---

我的个人主页，欢迎来阅读我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的Java-Spring入门指南知识文章专栏
欢迎来阅读指出不足
https://blog.csdn.net/2402_83322742/category_13040333.html?spm=1001.2014.3001.5482
我的MyBatis实战指南专栏（SSM前置必备）
https://blog.csdn.net/2402_83322742/category_12969707.html?spm=1001.2014.3001.5482

非常感谢您的阅读，喜欢的话记得持续关注哦！