Spring+SpringMVC+MyBatis整合项目实战（含完整源码）

本文还有配套的精品资源，点击获取

简介：本项目是一个基于Java的Web开发实战案例，整合了Spring、Spring MVC和MyBatis三大主流框架，构建典型的SSM技术栈应用。Spring作为核心容器，实现依赖注入与AOP编程；Spring MVC负责Web层请求处理，采用MVC架构提升可维护性；MyBatis作为持久层框架，简化数据库操作并支持原生SQL控制。项目包含完整的控制器、业务对象、数据访问层及配置文件，结构清晰，适用于学习框架整合、掌握企业级Java Web开发流程，也可作为后续项目的初始化模板。

SSM框架整合原理与项目搭建

在现代企业级Java开发中，构建一个稳定、高效且易于维护的Web应用离不开成熟的技术栈支撑。而SSM（Spring + Spring MVC + MyBatis）组合正是这样一个被广泛验证、久经考验的全栈解决方案。它不仅具备强大的功能集成能力，还兼顾了灵活性与可扩展性，尤其适合中小型项目的快速开发与迭代。

你是否也曾面对过这样的问题：为什么明明写了 @Service 注解，却提示找不到Bean？为什么事务没有生效，数据还是被提交了？又或者，在Controller里注入Mapper总是报空指针异常？

这些问题的背后，往往不是代码写错了，而是对SSM三大框架如何“握手言和”的底层机制理解不够深入。今天，我们就来揭开这层神秘面纱——不讲套话，不堆术语，从零开始，手把手带你搞懂SSM是怎么真正“串”起来的，并亲手搭出一个结构清晰、运行稳定的项目骨架 💻✨

---

想象一下，如果把整个Web应用比作一家餐厅：

• Spring 就是这家餐厅的“总经理”，负责统筹全局：谁当厨师、谁做服务员、食材从哪采购……全部由他调度；
• Spring MVC 是“前台接待+点餐系统”，专门处理顾客（客户端）的请求，决定该上什么菜（返回什么视图或数据）；
• MyBatis 则是“后厨大厨”，精通各种SQL烹饪技法，能把数据库里的原料变成一道道美味佳肴（Java对象）。

但这三个角色要想配合无间，光有分工还不够，还得有个“开业仪式”——也就是我们常说的 项目初始化流程 。这个仪式的核心任务就是：让总经理（Spring）认识每一位员工（Bean），并安排好他们的岗位职责。

那么，这个“开业仪式”究竟是怎么进行的呢？

首先，我们要用Maven来创建项目结构，这是现代Java工程的标准入场券 🎟️。引入几个关键依赖就相当于招聘核心团队成员：

<!-- Spring核心容器 -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>5.3.21</version>
</dependency>

<!-- Spring MVC模块 -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>5.3.21</version>
</dependency>

<!-- MyBatis持久层 -->
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.9</version>
</dependency>

<!-- MyBatis与Spring整合桥接器 -->
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis-spring</artifactId>
    <version>2.0.7</version>
</dependency>

<!-- 数据库驱动和连接池 -->
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.30</version>
</dependency>
<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>5.0.1</version>
</dependency>

看到 mybatis-spring 了吗？这家伙可是个“翻译官”！因为MyBatis原本不认识Spring那一套IoC容器的语言，有了它才能实现无缝对接 👏

接下来就是配置文件登场了。我们知道，Spring可以通过XML或者Java Config的方式管理Bean，而在传统的SSM项目中，通常采用双配置文件策略：

• applicationContext.xml ：总经理办公室，管全局Bean，比如数据源、事务管理器、Service层组件；
• spring-mvc.xml ：前台接待处，专管Web相关的事儿，比如Controller扫描、视图解析器、拦截器等。

这两个配置文件通过 web.xml 串联起来，就像公司的组织架构图一样层层上报 ⬆️：

<!-- web.xml 片段 -->

<!-- 1. 先启动Spring核心容器 -->
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:applicationContext.xml</param-value>
</context-param>

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!-- 2. 再启动Spring MVC的DispatcherServlet -->
<servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:spring-mvc.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

这里有个非常重要的细节： ContextLoaderListener 加载的是根上下文（Root ApplicationContext），而 DispatcherServlet 加载的是子上下文（Web ApplicationContext）。子可以访问父，但父不能访问子，这就保证了层次分明，避免循环依赖 ❗

举个例子，你在Service层注入了一个UserMapper，没问题；但如果想在Controller里直接使用某个只在根上下文中定义的数据源Bean，也没问题；反过来说，如果你试图在Service中去调用某个仅存在于Web上下文中的HandlerInterceptor，那就会失败——因为它“看不见”。

所以，最佳实践建议：

✅ 把DAO、Service、DataSource、TransactionManager这些通用组件放在 applicationContext.xml 中；
✅ 把Controller、ViewResolver、HandlerMapping等Web专属组件放在 spring-mvc.xml 中。

这样一来，整个项目的骨架就立住了。Spring作为总指挥，把MyBatis注册为DAO实现者，再把Spring MVC纳入麾下负责前端交互，三者各司其职又统一听命于IOC容器，真正实现了“控制反转”（IoC）与“依赖注入”（DI）的设计哲学。

当然啦，现在越来越多的新项目已经转向Spring Boot全自动装配模式，省去了大量手动配置。但了解这套传统SSM整合机制，不仅能帮助我们读懂老系统的代码，更能让我们明白：那些自动化背后，到底发生了什么？

毕竟，魔法再炫酷，也得知道咒语是怎么念的 ✨🧙‍♂️

---

Spring核心容器配置与Bean管理

你以为Spring只是个“装Bean的盒子”？错！它更像一台精密运转的宇宙引擎，掌控着每一个对象的生老病死。而这一切的起点，就藏在那个看似普通的 ApplicationContext 里。

还记得第一次写Spring程序时的情景吗？你小心翼翼地写下：

ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");
MyService service = context.getBean(MyService.class);

然后一运行，哇！居然拿到了一个活生生的对象！那一刻你可能没意识到——一场关于“对象生命周期”的革命，已经悄然发生 🌱

容器启动的秘密：不只是读配置那么简单

很多人以为，Spring容器启动就是把XML里的 <bean> 标签一个个解析出来，然后new一下完事。Too young too simple！

实际上，当你调用 new ClassPathXmlApplicationContext(...) 的时候，Spring已经在后台悄悄执行了一整套复杂的初始化流程。这套流程被封装在一个叫 refresh() 的方法里，整整 12个步骤 ，环环相扣，堪称教科书级别的设计模式典范。

我们可以把它想象成火箭发射前的倒计时 checklist 🔧：

graph TD
    A[调用 new AnnotationConfigApplicationContext(Config.class)] --> B[注册配置类]
    B --> C[创建 BeanFactory]
    C --> D[执行 refresh()]
    D --> E[obtainFreshBeanFactory(): 加载 BeanDefinition]
    E --> F[prepareBeanFactory(): 配置标准上下文特征]
    F --> G[postProcessBeanFactory(): 子类定制]
    G --> H[invokeBeanFactoryPostProcessors(): 处理 @Configuration 等元数据]
    H --> I[registerBeanPostProcessors(): 注册后处理器]
    I --> J[initMessageSource(): 初始化消息源]
    J --> K[initApplicationEventMulticaster(): 初始化事件广播器]
    K --> L[onRefresh(): 特定上下文刷新（如 MVC 容器）]
    L --> M[registerListeners(): 注册监听器]
    M --> N[finishBeanFactoryInitialization(): 实例化所有非懒加载单例 Bean]
    N --> O[finishRefresh(): 发布 ContextRefreshedEvent]
    O --> P[容器准备就绪]

是不是感觉有点眼花缭乱？别急，咱们挑几个最关键的环节拆开看看。

第一步：加载 BeanDefinition

Spring不会直接创建对象，而是先把你定义的每个Bean包装成一个叫做 BeanDefinition 的元数据对象。你可以把它理解为“图纸”——上面写着这个Bean叫啥名字、属于哪个类、构造函数参数是什么、属性值有哪些、作用域是singleton还是prototype……

// 比如你写了这么一段XML
<bean id="userService" class="com.example.UserServiceImpl">
    <property name="userRepository" ref="userRepository"/>
</bean>

// Spring会把它转成一个 BeanDefinition 对象
BeanDefinition bd = new RootBeanDefinition();
bd.setBeanClass(UserServiceImpl.class);
bd.getPropertyValues().add("userRepository", new RuntimeBeanReference("userRepository"));

这一步完成后，Spring手里就有了所有Bean的“蓝图”，但还没开始盖房子。

第二步：处理@Configuration类

这是Spring注解驱动开发的核心魔法所在。当你在一个类上加上 @Configuration ，Spring并不会直接实例化它，而是通过 ConfigurationClassPostProcessor 这个后处理器，对它进行CGLIB增强。

什么意思呢？简单说，就是Spring偷偷给你生成了一个子类，在每次调用 @Bean 方法之前，先检查有没有缓存实例——如果有，就直接返回缓存的；如果没有，才真正去new一个。

这就保证了即使你在多个地方调用了同一个 @Bean 方法，返回的也是同一个对象，完美实现了singleton语义 ✅

第三步：注册BeanPostProcessor

这是一群“潜伏者”。它们本身也是Bean，但在其他Bean创建过程中会悄悄介入，做一些增强操作。比如：

• AutowiredAnnotationBeanPostProcessor ：负责处理 @Autowired 、 @Value 等注入注解；
• CommonAnnotationBeanPostProcessor ：支持 @Resource 、 @PostConstruct 等JSR-250注解；
• AnnotationAwareAspectJAutoProxyCreator ：AOP代理生成的关键人物！

这些后处理器必须在普通Bean实例化之前注册好，否则就来不及发挥作用了。

最后一步：实例化所有单例Bean

终于到了“盖房子”的阶段！Spring遍历所有的BeanDefinition，发现是singleton且非lazy-init的，就开始逐个创建。

这里有个重要逻辑： 依赖解析是递归进行的 。比如你要创建UserService，发现它依赖UserRepository，那就先去创建UserRepository；如果UserRepository又依赖DataSource，那就继续往前找……直到整个依赖链条都被满足。

而且Spring很聪明，它会把已经创建好的singleton实例缓存在 singletonObjects 缓存池里，下次再要同一个Bean时，直接从池子里拿，绝不重复制造。

整个过程就像一场精心编排的交响乐，每一个音符都有它的位置和节奏。而这首曲子的名字，就叫 refresh() 。

Bean的作用域：不只是singleton和prototype

说到Bean的作用域，大多数人只知道两个： singleton （默认）和 prototype 。但你知道吗？Spring其实支持五种作用域：

作用域	描述	使用场景
singleton	每容器一个实例	默认，大多数无状态服务
prototype	每次getBean都新建	有状态对象，如用户会话
request	每HTTP请求一个实例	Web环境，保存请求上下文
session	每用户会话一个实例	用户登录态相关
application	每ServletContext一个实例	全局共享数据

不过要注意：request/session/application这三种作用域只能在Web环境下使用，而且需要配合 <aop:scoped-proxy/> 或 @Scope(proxyMode=TARGET_CLASS) 才能正确注入到singleton Bean中。

举个例子：

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class RequestContext {
    private String traceId = UUID.randomUUID().toString();

    public String getTraceId() { return traceId; }
}

如果不加 proxyMode ，当你在一个singleton Service中注入这个request-scoped Bean时，Spring会在Service初始化时尝试创建RequestContext——但那时根本没有HTTP请求上下文啊！直接抛异常 💥

加上代理之后，注入的其实是一个代理对象，真正的目标对象会在每次请求到来时动态创建，完美解决作用域冲突问题。

生命周期钩子：掌控对象的一生

Spring不仅能帮你创建对象，还能让你参与它的“出生”和“死亡”。

最常见的三种方式：

1. XML配置 ： init-method 和 destroy-method
2. 实现接口 ： InitializingBean / DisposableBean
3. 使用注解 ： @PostConstruct / @PreDestroy

推荐优先使用第三种，因为它是Java EE标准，不依赖Spring特定API，移植性更好。

@Component
public class CacheService {

    @PostConstruct
    public void init() {
        System.out.println("🎉 缓存预热开始...");
        // 加载热点数据
    }

    @PreDestroy
    public void cleanup() {
        System.out.println("🧹 清理缓存资源...");
        // 关闭线程池、释放连接
    }
}

此外，还有一个更高级的扩展点： BeanPostProcessor 。它可以在任何Bean初始化前后插入自定义逻辑，被广泛用于AOP、缓存、监控等横切关注点。

比如你想给所有标记了 @Cached 的方法自动加上缓存代理：

@Component
public class CachingBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (bean.getClass().isAnnotationPresent(Cached.class)) {
            return Proxy.newProxyInstance(
                bean.getClass().getClassLoader(),
                bean.getClass().getInterfaces(),
                (proxy, method, args) -> {
                    System.out.println("📦 缓存命中检测: " + method.getName());
                    // 这里可以接入Redis或其他缓存实现
                    return method.invoke(bean, args);
                });
        }
        return bean;
    }
}

这种机制正是Spring AOP的底层基础。所以说，掌握了 BeanPostProcessor ，你就摸到了Spring最强大武器的扳机 🛠️💥

---

依赖注入（DI）与面向切面编程（AOP）实践

如果说IoC是Spring的灵魂，那DI就是它的血液，而AOP则是它的神经系统。三者协同工作，让我们的代码变得前所未有的灵活与优雅。

构造器注入 vs Setter注入：选哪个？

这个问题曾经困扰了无数开发者。答案其实很简单： 优先使用构造器注入 。

为什么？

因为构造器注入能确保对象在创建完成时就处于完整状态，避免出现“半成品”对象被误用的情况。而且配合 final 关键字，还能实现不可变性，提升线程安全性。

@Service
@RequiredArgsConstructor
public class OrderService {
    private final PaymentService paymentService;
    private final InventoryService inventoryService;

    public void placeOrder(Order order) {
        inventoryService.reduceStock(order.getProductId());
        paymentService.processPayment(order.getAmount());
    }
}

看到了吗？一行 @RequiredArgsConstructor 搞定所有依赖注入，既简洁又安全。相比之下，Setter注入虽然灵活，但容易导致对象状态不一致，尤其是在多线程环境下风险更高。

当然，也有例外情况。比如某些可选依赖，或者为了打破循环依赖不得不使用Setter注入时，也可以接受。但请记住： 能用构造器的地方，绝不用Setter 。

自动装配的艺术：@Autowired背后的真相

@Autowired 看起来像个黑盒，其实它的运作机制非常清晰：

1. Spring首先根据类型（byType）查找匹配的Bean；
2. 如果找到多个，则再根据名称（byName）筛选；
3. 如果仍然不唯一，就抛出 NoUniqueBeanDefinitionException ；
4. 此时你需要用 @Qualifier("beanName") 来明确指定。

@Autowired
@Qualifier("jsonParser")
private Parser parser;

另一种选择是 @Resource ，它是Java EE标准， 默认按名称注入 ：

@Resource(name = "xmlParser")
private Parser parser;

两者对比：

注解	来源	装配策略	是否支持@Qualifier
@Autowired	Spring	byType → byName	是
@Resource	Java EE	byName → byType	否

建议在纯Spring项目中使用 @Autowired + @Qualifier 组合，更加精准可控。

AOP实战：用切面解放你的业务代码

你有没有遇到过这种情况：每个Service方法开头都要记录日志，结尾要统计耗时，出了异常还要发告警……结果业务代码被一堆非功能性代码淹没？

这时候，就该AOP出场了！

@Aspect
@Component
@Slf4j
public class OperationLogAspect {

    @Around("@annotation(com.example.annotation.LogOperation)")
    public Object recordOperation(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.currentTimeMillis();
        String methodName = pjp.getSignature().getName();

        try {
            Object result = pjp.proceed();
            log.info("✅ Method {} executed in {} ms", methodName, System.currentTimeMillis() - start);
            return result;
        } catch (Exception e) {
            log.error("❌ Method {} failed: {}", methodName, e.getMessage());
            throw e;
        }
    }
}

只需要定义一次切面，就能自动给所有标记了 @LogOperation 的方法加上日志和性能监控，业务代码干干净净，清爽得让人想哭 😭

而且Spring AOP底层基于动态代理，要么用JDK原生Proxy（要求实现接口），要么用CGLIB字节码增强（适用于普通类）。你可以通过 @EnableAspectJAutoProxy(proxyTargetClass=true) 强制使用CGLIB。

---

Spring MVC架构设计与Controller实现

当HTTP请求敲响服务器的大门，第一个迎接它的，就是那位勤劳的“门卫”—— DispatcherServlet 。

它不像普通的Servlet那样直接处理业务，而是扮演着“指挥官”的角色，协调九大组件共同完成一次完整的请求响应 cycle。

整个流程可以用一句话概括：

“我不管你怎么干，反正最后要把结果给我！”

具体来说，它会依次询问：

• HandlerMapping：“这个请求归谁管？”
• HandlerAdapter：“你能搞定这个Handler吗？”
• ViewResolver：“这个名字对应的页面在哪？”
• HandlerExceptionResolver：“出错了怎么办？”

正是这种高度解耦的设计，让我们可以轻松替换任意组件，实现个性化定制。

比如你想让URL支持 .html 后缀但仍走同一个Controller，只需配置：

@Configuration
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        configurer.setUseSuffixPatternMatch(true);
    }
}

瞬间就拥有了更友好的SEO URL！

至于Controller开发，记住几个黄金法则：

1. RESTful API用 @RestController ，传统页面跳转用 @Controller ；
2. 路径映射优先使用 @GetMapping / @PostMapping 等派生注解，更直观；
3. 参数绑定善用 @RequestParam 、 @PathVariable 、 @RequestBody ；
4. 返回值尽量使用 ResponseEntity<T> ，便于控制状态码和Header。

@RestController
@RequestMapping("/api/users")
public class UserController {

    @GetMapping("/{id}")
    public ResponseEntity<UserDto> getUser(@PathVariable Long id) {
        User user = userService.findById(id);
        if (user == null) {
            return ResponseEntity.notFound().build();
        }
        return ResponseEntity.ok(convertToDto(user));
    }
}

简洁明了，语义清晰，这才是现代化API应有的样子 ✨

---

请求处理与视图响应

在前后端分离已成为主流的今天，你还需不需要掌握JSP和视图解析？

答案是： 需要 。

不是为了天天写JSP，而是为了理解Spring MVC完整的响应机制。哪怕你现在只返回JSON，背后的 HttpMessageConverter 、 ContentNegotiatingViewResolver 等工作原理，依然源自这一套体系。

比如你想实现文件下载功能，防止路径穿越攻击：

@GetMapping("/download/{filename}")
public void downloadFile(@PathVariable String filename, 
                        HttpServletResponse response) throws IOException {

    // 安全校验
    if (filename.contains("..")) {
        throw new IllegalArgumentException("Invalid path");
    }

    Path filePath = Paths.get("uploads", filename);
    if (!Files.exists(filePath)) {
        response.sendError(404);
        return;
    }

    response.setContentType(Files.probeContentType(filePath));
    response.setContentLength((int) Files.size(filePath));
    response.setHeader("Content-Disposition", 
                      "attachment; filename=\"" + URLEncoder.encode(filename, "UTF-8") + "\"");

    Files.copy(filePath, response.getOutputStream());
}

短短几十行代码，涉及MIME类型探测、安全编码、流式传输等多个知识点，全是基本功的体现。

---

MyBatis持久层配置与SQL映射

终于来到最后一站——MyBatis。

如果说Spring是大脑，Spring MVC是四肢，那MyBatis就是心脏，为整个系统提供源源不断的数据动力 ❤️

它的设计理念非常明确： 让SQL重回程序员的掌控之中 。

不再像Hibernate那样试图屏蔽SQL，而是坦然接受它的存在，并通过优雅的方式加以管理。

XML vs 注解：怎么选？

简单CRUD用注解，复杂查询用XML，就这么简单。

@Mapper
public interface UserMapper {
    @Select("SELECT * FROM users WHERE id = #{id}")
    User selectById(Long id);

    @Insert("INSERT INTO users(...) VALUES(...)")
    @Options(useGeneratedKeys = true, keyProperty = "id")
    int insert(User user);
}

但对于多表JOIN、动态条件拼接，XML显然更具优势：

<select id="findUsers" parameterType="map" resultType="User">
    SELECT u.*, d.name as deptName 
    FROM users u 
    LEFT JOIN departments d ON u.dept_id = d.id
    <where>
        <if test="deptId != null">AND u.dept_id = #{deptId}</if>
        <if test="keyword != null">
            AND (u.name LIKE CONCAT('%',#{keyword},'%') 
                 OR u.email LIKE CONCAT('%',#{keyword},'%'))
        </if>
    </where>
</select>

特别是 <choose><when><otherwise> 这类结构化标签，写起来比Java拼字符串舒服太多了。

事务管理：@Transactional真的可靠吗？

很多人以为只要加个 @Transactional 注解，事务就稳了。错！

有几个坑必须避开：

1. 私有方法无效 ：只有public方法才能被AOP代理拦截；
2. 同类调用失效 ：this.method()不会触发代理；
3. 异常被捕获 ：默认只对unchecked exception回滚；
4. 传播行为误解 ：REQUIRES_NEW不一定新建事务。

正确的做法是：

@Service
@Transactional
public class UserService {

    @Autowired
    private UserMapper userMapper;

    public void createUser(User user) {
        userMapper.insert(user);
        // 如果这里抛异常，整个事务都会回滚
    }
}

必要时显式指定rollbackFor：

@Transactional(rollbackFor = Exception.class)
public void businessMethod() throws BusinessException {
    // 即使是checked exception也会回滚
}

---

至此，我们完成了对SSM三大框架的深度巡礼。从容器启动到Bean管理，从依赖注入到AOP切面，从请求分发到SQL映射，每一步都凝聚着设计者的智慧与匠心。

希望这篇文章能让你不再只是“会用”Spring，而是真正“懂”Spring。毕竟，掌握原理的人，才有资格驾驭技术 🚀

本文还有配套的精品资源，点击获取

简介：本项目是一个基于Java的Web开发实战案例，整合了Spring、Spring MVC和MyBatis三大主流框架，构建典型的SSM技术栈应用。Spring作为核心容器，实现依赖注入与AOP编程；Spring MVC负责Web层请求处理，采用MVC架构提升可维护性；MyBatis作为持久层框架，简化数据库操作并支持原生SQL控制。项目包含完整的控制器、业务对象、数据访问层及配置文件，结构清晰，适用于学习框架整合、掌握企业级Java Web开发流程，也可作为后续项目的初始化模板。

本文还有配套的精品资源，点击获取