瞅了一眼，距离上次写这个系列的文章已经两个半月了。其实早就想写了，但迟迟没有动手，不是不想，是担心写不好。因为要讲概念性的东西，搞不好就会误人子弟，所以不但要靠知识储备、要靠灵感，还要找到最佳的写作状态。我很佩服那些两三天甚至是每天都能出篇文章的博主，每次我憋出一篇文章都至少要三四个小时，也就周末有这个时间啦。
虽说我只是一个不知名的技术博主，一个平平无奇的程序猿，但离奇地获得了一些读者的支持。虽然文章很难写的大家都满意，但目前来看，认可的成分还是多一些的。所以我打算无论如何坚持下去，我王境泽，绝对不弃坑。
前言
使用框架是为了提高我们的开发效率。同时由于开发框架的大都是大佬级别的人物，所以通用的功能往往能得到较大的优化，我们要做的是优中选优。当然，在实际生产中一个框架是否被采用取决于很多因素，不能片面地认为哪种框架在任何情况下都是更好的。
一、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 情有独钟。（国外的开发者们似乎更喜欢 Hibernate）
分割线以下提一嘴，也有人用 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 的这套模式叫 “约定大于配置”，总觉得自动化程度高了就不够灵活，不够好，就像一部分大佬喜欢用文本编辑器做开发。
如何选择仁者见仁智者见智，我只是觉得，降低门槛是编写框架的人的追求，未来的开发只会更加自动化，我们所考虑的由于降低灵活性带来的种种问题，人家一帮子牛人天天琢磨着怎么改进呐。