Hi,大家好,我是编程小6,很荣幸遇见你,我把这些年在开发过程中遇到的问题或想法写出来,今天说一说JavaEE 从入门到放弃(五):框架SSH&SSM怎么选择「终于解决」,希望能够帮助你!!!。
使用框架是为了提高我们的开发效率。同时由于开发框架的大都是大佬级别的人物,所以通用的功能往往能得到较大的优化,我们要做的是优中选优。当然,在实际生产中一个框架是否被采用取决于很多因素,不能片面地认为哪种框架在任何情况下都是更好的。
SSH 和 SSM 之争由来已久,但正如某不知名技术博主所说,他们的江湖并不是你死我活。
SSH 最经典的定义是 Spring + Struts(2)+ Hibernate ,形成这个组合是自然而然的,因为过去这仨框架比较牛,组合起来可以解决很多方面的问题,而且当时 Spring 还没有那么枝繁叶茂(见 「JavaEE 从入门到放弃(五):如何理解 Spring」 ),还需要 Struts 大兄弟提供帮助。
在 SSH 中,Spring 提供了 IoC(控制反转)和 AOP(面向切面编程)功能,用于降低应用开发的复杂性,有效地实现解耦,并提高可测试性。
Struts 分为 Struts 1 和 Struts 2,这两个框架名字虽然类似,但实际上差异很大。两者并行更新了一段时间,后来 Struts 1 就不再更新了,这大概是 08 年的事情,所以我们现在谈论 Struts 时,通常是指 Struts 2。
Struts 框架采用 MVC 架构,也就是说它的作用是——为用户开发 MVC 架构的应用提供便利。
Hibernate 是用来操纵数据库的框架。为什么需要这个东西呢?主要原因如下:
Hibernate 是一个 ORM(Object Relational Mapping,对象关系映射) 框架,所谓 ORM,即通过使用描述对象和数据库之间关系的元数据,将面向对象语言程序中的对象持久化到关系数据库中。说人话就是,通过一些简单配置,把 Java 类(一般是普通的 Bean
)跟数据库表对应起来,这样就可以通过操作类来操作数据库。
Hibernate 比较自动化,只要写个方法名就可以自动生成 SQL 语句,用起来贼拉方便。这里插一句,SSM 中的 MyBatis 跟 Hibernate 是对应的,两者最大的差别就是 MyBatis 并非自动生成 SQL,而是根据需要自行编写,一般来讲,手动挡比自动挡要省油,所以国内的许多公司对 MyBatis 情有独钟。(国外的开发者们似乎更喜欢 Hibernate)
分割线以下提一嘴,也有人用 Spring + SpringMVC + Hibernate 这种组合,这个的缩写也是 SSH,有时候会造成混淆。
SSM 指 Spring + SpringMVC + MyBatis ,目前没什么歧义。讲道理 SpringMVC 是 Spring 生态的一部分,这俩算是一个框架,区分开写是因为大家还是会习惯性地把 Spring 当成是过去的 Spring,也就是实现 IoC 和 AOP 的那一部分。说起来,如果把前俩当成一个框架,岂不是缩写就成了 SM。。。
SSM 和 SSH 是对应的。SpringMVC 和 Struts 有什么区别呢?相对来讲,SpringMVC 的使用更加方便,几乎做到了零配置,而且人家本来就是 Spring 家的,根本不存在整合这个问题,使用起来更顺畅、更安全。
至于 Hibernate 和 Mybatis 的区别,除了上面提到过的自动程度与性能的问题,还有以下几个方面:
目前倾向使用 MyBatis 的人比较多,它和 Hibernate 之间我认为说不上好坏,看进一步的发展吧。像我大 Java ,刚诞生之时性能一塌糊涂,也没有多么优美的语法,但就是一路坚挺了过来。
前面提到过,SSM 中的前俩 S 都是 Spring 家的,不需要整合就用在一起了,还剩一个 M。对于开发者来说,重复的搭建项目、配置整合搞来搞去没啥意义,于是 Spring 背后的势力就想把这个过程给自动化,整出了个 Spring Boot。
Spring Boot 的作用似乎只是用于启动一个项目,是一个类似脚手架的东西,但其实随着它自身的发展,其含义已经接近于一个完整的框架,快速配置项目是这个框架的一个功能子集。
有些人喜欢说 “整合” Spring Boot 和 SSM,前俩 SS 还整合个锤锤啊,用 Spring Boot 直接创建的 Web 项目就包含了 SpringMVC,人家写的这么清楚。Spring 就更不用说了,创建的各种项目都包含它了啊。
MyBatis 是独立的项目,但也只是需要勾选一下
目前 Spring 是还没出啥能替代 MyBatis 的东西,出了之后妥妥地一条龙,其它家的东西可能就靠边站了。不过反正大家都是开源的,开开心心好聚好散喽。
有人管 Spring Boot 的这套模式叫 “约定大于配置”,总觉得自动化程度高了就不够灵活,不够好,就像一部分大佬喜欢用文本编辑器做开发。
如何选择仁者见仁智者见智,我只是觉得,降低门槛是编写框架的人的追求,未来的开发只会更加自动化,我们所考虑的由于降低灵活性带来的种种问题,人家一帮子牛人天天琢磨着怎么改进呐。