🍺Jakarta EE & Spring

Spring 体系结构

2022-11-10  本文已影响0人  en_young

秉徇【先有问题,才有方案】


🍺Spring 其实就是提供了 J2EE 之外的另一种可能,它在产生自己的规范的同时,也在不断吸收 J2EE 的优秀内容。

1. Spring1.0

1.1 问题

Rod Johnson 认为 JavaEE 规范过于繁琐,实际上仅依靠 Web Container 部分的规范即可开发出企业应用。

与此同时,JavaEE 1.4 及以前的版本中,都是用代码来写配置的,非常繁琐,往往一个简单的 Hello World 启动都需要写几十行配置代码。

1.2. 方案

提出 Spring1.0,Spring1.0 只遵循了 J2EE 中的 Web Container 部分的规范,以及正式引入了 AOP 和 IOC 两大核心特性,AOP 对应图 1 中的 Spring AOP 模块,IOC 对应图 1 中 Spring Context 模块。AOP 和 IOC 大大简化了代码,加快程序开发的速度。

Spring1.0(2004.3)体系结构 XML配置示例

同时,Spring 1.0 使用 XML 文件来配置组件,组件也就是 Bean 对象。使用文件来配置的好处是,编译好的代码后期不需要再重新更改打包了,只需要修改配置文件即可。坏处是安全性问题,就是服务器上的配置文件一旦被恶意修改就糟了,当然后来 Spring 也慢慢收回了这个特性,但这在当时是让大家耳目一新又为之兴奋的东西。

2. Spring2.0

Spring2.0(2006.10)体系结构

🔥2.1 主要调整

3. Spring2.5

🔥3.1 主要调整

🔥注解配置和自动扫描使得 Spring 的配置工作大幅度地减少,减少了 70% 以上。

4. Spring3.0

Spring3.0(2009.12)体系结构

🔥4.1 主要调整

引入 Java 配置方式,即用程序来写配置。为什么又重新用代码来写配置了?
💡因为发现自动扫描和注解形成的默认配置存在问题,有些时候不能用默认配置,比如某个配置在那儿,但是要求不能用它。
💡如果用传统的方式 XML 来写,麻烦而且不安全。所以姑且改用最原始的 Java 代码的方式。
💡注意,这种方式并不是用 Java 代码写所有的东西,而是当某个配置不能当作默认配置时候用 Java 代码来写。
💡用 Java 代码写配置,一来因为要编译所以不容易编写错误;二来编译完是不能更改的,所以也会更安全。

5. Spring4.3

🔥5.1 主要调整

💡引入 SpringBoot,使得 Spring 项目的配置再次大幅度地减少。

💡原来的工作包括:注解、自动扫描、Java代码、配置和管理复杂的依赖关系,这些工作在 SpringBoot 中一键性解决。SpringBoot 以一种默认的方式去管理依赖以及依赖的配置。

💡从此以后没有人再愿意直接使用 Spring,Spring 和 SpringBoot 画上了等号。

6. Spring5.0(2017.9)

Spring5.0(2017.9)

🔥6.1 主要调整

💡跟着 JavaEE 学,加入了响应式编程。
因为响应式编程是高并发,高负载的一个非常有效的解决方案。响应式编程其实用的就是函数式编程。
函数式编程和传统的命令式编程是不同的,设计方法和编程的方式都不同。任何东西能用命令式编程做出来,但是不一定能用函数式编程解决,数学上是可以,万事万物是函数,但实际解决问题的时候还有些没有触及的内容,还在探索中。

💡Spring5.0 开始被分成了 Servlet Stack 和 Reactive Stack 两条线。Servlet Stack 是传统的 Spring 的内容,是命令式编程;Reactive Stack 则是函数式编程。

💡如上图所示,两条线是完全不同的,除了 SpringBoot 是一样的,因为 SpringBoot 是没内容的,因为它就是去管理依赖、管理配置信息的。

7. Spring6.0

🔥7.1 主要调整

8. 赘述

Go 语言是完全基于云来设计的,在云原生应用方面有着强势的竞争力,Spring 已然做出反应,例如 SpringBoot3.0 支持云原生,Java EE 必然也会做出反应。

上一篇下一篇

猜你喜欢

热点阅读