瞅了一眼，距离上次写这个系列的文章已经两个半月了。其实早就想写了，但迟迟没有动手，不是不想，是担心写不好。因为要讲概念性的东西，搞不好就会误人子弟，所以不但要靠知识储备、要靠灵感，还要找到最佳的写作状态。我很佩服那些两三天甚至是每天都能出篇文章的博主，每次我憋出一篇文章都至少要三四个小时，也就周末有这个时间啦。

虽说我只是一个不知名的技术博主，一个平平无奇的程序猿，但离奇地获得了一些读者的支持。虽然文章很难写的大家都满意，但目前来看，认可的成分还是多一些的。所以我打算无论如何坚持下去，我王境泽，绝对不弃坑。

前言

使用框架是为了提高我们的开发效率。同时由于开发框架的大都是大佬级别的人物，所以通用的功能往往能得到较大的优化，我们要做的是优中选优。当然，在实际生产中一个框架是否被采用取决于很多因素，不能片面地认为哪种框架在任何情况下都是更好的。

一、SSH 与 SSM 之争

SSH 和 SSM 之争由来已久，但正如某不知名技术博主所说，他们的江湖并不是你死我活。

1.SSH

SSH 最经典的定义是 Spring + Structs(2)+ Hibernate ，形成这个组合是自然而然的，因为过去这仨框架比较牛，组合起来可以解决很多方面的问题，而且当时 Spring 还没有那么枝繁叶茂(见 「JavaEE 从入门到放弃(五)：如何理解 Spring」 )，还需要 Structs 大兄弟提供帮助。

在 SSH 中，Spring 提供了 IoC(控制反转)和 AOP(面向切面编程)功能，用于降低应用开发的复杂性，有效地实现解耦，并提高可测试性。

Structs 分为 Structs 1 和 Structs 2，这两个框架名字虽然类似，但实际上差异很大。两者并行更新了一段时间，后来 Structs 1 就不再更新了，这大概是 08 年的事情，所以我们现在谈论 Structs 时，通常是指 Structs 2。

Structs 框架采用 MVC 架构，也就是说它的作用是——为用户开发 MVC 架构的应用提供便利。

Hibernate 是用来操纵数据库的框架。为什么需要这个东西呢？主要原因如下：

使用 JDBC 操作数据库时，SQL 语句都被编写在代码里面(硬编码)，需要调整就得修改源码，灵活性差

每写一条操作都要创建一个 connection，这玩意儿十分消耗资源

对查询结果的解析、对参数的设置等，都与 SQL 语句有关，牵一发而动全身，耦合度极高

Hibernate 是一个 ORM(Object Relational Mapping，对象关系映射) 框架，所谓 ORM，即通过使用描述对象和数据库之间关系的元数据，将面向对象语言程序中的对象持久化到关系数据库中。说人话就是，通过一些简单配置，把 Java 类(一般是普通的 Bean

)跟数据库表对应起来，这样就可以通过操作类来操作数据库。

Hibernate 比较自动化，只要写个方法名就可以自动生成 SQL 语句，用起来贼拉方便。这里插一句，SSM 中的 MyBatis 跟 Hibernate 是对应的，两者最大的差别就是 MyBatis 并非自动生成 SQL，而是根据需要自行编写，一般来讲，手动挡比自动挡要省油，所以追求性能的项目会更倾向于使用 MyBatis。

分割线以下提一嘴，也有人用 Spring + SpringMVC + Hibernate 这种组合，这个的缩写也是 SSH，有时候会造成混淆。

2.SSM

SSM 指 Spring + SpringMVC + MyBatis ，目前没什么歧义。讲道理 SpringMVC 是 Spring 生态的一部分，这俩算是一个框架，区分开写是因为大家还是会习惯性地把 Spring 当成是过去的 Spring，也就是实现 IoC 和 AOP 的那一部分。说起来，如果把前俩当成一个框架，岂不是缩写就成了 SM。。。

SSM 和 SSH 是对应的。SpringMVC 和 Structs 有什么区别呢？相对来讲，SpringMVC 的使用更加方便，几乎做到了零配置，而且人家本来就是 Spring 家的，根本不存在整合这个问题，使用起来更顺畅、更安全。

至于 Hibernate 和 Mybatis 的区别，除了上面提到过的自动程度与性能的问题，还有以下几个方面：

Mybatis 更加轻量(废话，自动当然麻烦些)

Mybatis 对于写惯了 SQL 语句的开发者来说更简单易学(我就没有这种感觉)

Hibernate 有更好的二级缓存机制，而且可以使用第三方缓存(这个问题比较复杂)

目前倾向使用 MyBatis 的人比较多，它和 Hibernate 之间我认为说不上好坏，看进一步的发展吧。像我大 Java ，刚诞生之时性能一塌糊涂，也没有多么优美的语法，但就是一路坚挺了过来。

二、Spring Boot 的野心

前面提到过，SSM 中的前俩 S 都是 Spring 家的，不需要整合就用在一起了，还剩一个 M。对于开发者来说，重复的搭建项目、配置整合搞来搞去没啥意义，于是 Spring 背后的势力就想把这个过程给自动化，整出了个 Spring Boot。

Spring Boot 的作用似乎只是用于启动一个项目，是一个类似脚手架的东西，但其实随着它自身的发展，其含义已经接近于一个完整的框架，快速配置项目是这个框架的一个功能子集。

有些人喜欢说 “整合” Spring Boot 和 SSM，前俩 SS 还整合个锤锤啊，用 Spring Boot 直接创建的 Web 项目就包含了 SpringMVC，人家写的这么清楚。Spring 就更不用说了，创建的各种项目都包含它了啊。

MyBatis 是独立的项目，但也只是需要勾选一下

目前 Spring 是还没出啥能替代 MyBatis 的东西，出了之后妥妥地一条龙，其它家的东西可能就靠边站了。不过反正大家都是开源的，开开心心好聚好散喽。

有人管 Spring Boot 的这套模式叫 “约定大于配置”，总觉得自动化程度高了就不够灵活，不够好，就像一部分大佬喜欢用文本编辑器做开发。

如何选择仁者见仁智者见智，我只是觉得，降低门槛是编写框架的人的追求，未来的开发只会更加自动化，我们所考虑的由于降低灵活性带来的种种问题，人家一帮子牛人天天琢磨着怎么改进呐。