<svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> 

Spring 是最基础的框架，Spring MVC 专注于 Web 层，Spring Boot 则通过自动化配置和内嵌服务来简化 Spring 应用的开发。

1. Spring 是基础框架，提供了 IoC、AOP 等核心功能，帮助解决企业级开发中的问题。
2. Spring MVC 是 Spring 的一个模块，专注于 Web 层的 MVC 开发，帮助构建基于 Web 的应用程序。
3. Spring Boot 是一个基于 Spring 的快速开发框架，可以快速的集成其他框架进来，比如想使用SpringBoot 开发 Web 项目, 只需要引入 Spring MVC 框架即可。

用⼀句更具体的话来概括 Spring,：包含了众多工具方法的 IoC 容器，那什么是 IoC 容器呢？接下来我们⼀起来看看

IoC 是一种通过容器来管理对象之间依赖关系的设计原则。在传统编程中，程序员需要在代码中明确创建和管理对象的实例及其依赖项。而在 IoC 中，对象的创建和依赖管理被反转给容器来处理。也就是说，不再由代码“主动”创建对象，而是由容器“被动”提供所需要的依赖，为了更好地理解控制反转，我们可以通过类比汽车制造的过程来讲解。

1.2.1 没有 IoC 的情况下

在没有 IoC 的情况下，汽车制造商需要自己承担所有的工作，包括生产每个零件和组装汽车。这种方式带来了几个问题：

• 高耦合性：汽车制造商不仅要负责设计和组装汽车，还需要负责制造所有的零件，如引擎、轮胎、车门、方向盘等。这就意味着汽车制造商的职责范围非常广，几乎要自己做所有事情。制造商和零件之间的关系变得紧密耦合，这意味着如果需要更换某个零件的供应商或者零件发生变化，汽车制造商的整个生产流程都需要改变。
• 复杂性：生产汽车的过程变得非常复杂，因为汽车制造商不仅要关注如何设计和装配汽车，还要花费大量的精力和资源去确保每个零件的质量、供应、研发等。每次制造新车型，制造商都需要重新考虑所有的零件生产和组装过程。
• 不可扩展性：如果需要生产一种新的车型，或者引入新的零件，制造商可能需要彻底修改现有的生产线。这会导致整个制造过程非常不灵活，成本和时间消耗也会增加。

1.2.2 有 IoC 的情况下

有了 IoC 之后，控制权从“汽车制造商”转移到了“供应商”或“第三方服务”。汽车制造商不再需要自己制造每一个零件，而是将零件的生产交给各自的供应商，自己只负责整体的设计和装配。

1. 解耦合：
   • 在有 IoC 的模式下，汽车制造商不再直接依赖每个零件，而是依赖于供应商提供的标准接口。例如，汽车制造商只需要规定“我需要一个符合某些规格的引擎”，然后由供应商提供符合这些规格的引擎，而制造商不关心引擎是如何制造出来的。
   • 汽车制造商与具体零件之间的耦合性降低。制造商只需要知道如何使用这些零件，而不是负责生产它们。
2. 简化工作流程：
   • 有了 IoC 之后，汽车制造商的主要工作从“制造每一个零件”转变为“设计和组装”。他们只需要明确每辆车所需的零件，并从不同的供应商那里获得这些零件。这使得制造商可以专注于汽车的整体设计和优化，而不必浪费精力去处理零件的生产细节。
   • 这和在编写代码时，程序员不需要自己去创建和管理依赖对象，而是由 IoC 容器自动管理和注入这些依赖。程序员可以专注于业务逻辑，而不必关心如何创建和管理对象。
3. 灵活性与可扩展性：
   • 当汽车制造商需要为新车型配备更高性能的引擎时，他们可以选择更换引擎供应商，而不需要改变现有的装配线或生产流程。比如，当一种更先进的电动引擎出现时，汽车制造商可以很容易地从燃油引擎切换到电动引擎，只需要从新的供应商那里获取电动引擎。
4. 提升质量和专注专业性：
   • 供应商是生产各自领域零件的专家，他们可以为汽车制造商提供高质量的引擎、轮胎和其他组件。每个供应商专注于生产他们最擅长的零件，从而确保零件的质量比由汽车制造商自己生产更好。汽车制造商可以专注于自己的核心业务，即设计和组装高质量的汽车。
   • 在 IoC 中，Spring 容器可以整合各个领域的组件，比如数据访问层、业务逻辑层、服务层等等。每个模块可以独立发展并保持专业性，开发者可以专注于不同层的逻辑，而 IoC 容器负责将它们组合在一起。
5. 降低维护成本：
   • 如果某个供应商的零件出了问题，汽车制造商只需要联系供应商更换零件，而不必完全重新设计或修改自己的生产线。这极大地减少了维修和维护的成本，因为供应商提供的标准化接口和服务使得更换零件变得简单高效。
   • 在代码层面，当需要对依赖进行修改时，比如将一个服务切换到一个新的实现，开发者只需要修改 Spring 容器中的配置文件或注解，而不必修改应用中的业务逻辑。这大大减少了维护成本和出错的风险。

1.2.3 代码类比

1. 没有 IoC 的情况下，汽车必须自己创建它所依赖的所有零件：

讯享网

这段代码会输出：

讯享网

2. 引入 IoC 使用依赖注入，我们可以通过构造器注入的方式，将依赖项交给 Car 类，而不再让它自己创建。

讯享网

这段代码将会输出：

依赖注入是一种设计模式，用于实现控制反转，其主要目的是将对象的依赖关系从类内部解耦出来，由外部来管理这些依赖的注入，从而达到类之间的松耦合。简单来说，依赖注入是一种将对象所需的依赖项从外部传递进来的方式，而不是在类内部自己创建依赖。

上述代码中, 是通过构造函数的方式, 把依赖对象注入到需要使用的对象中的

Spring 是⼀个 IoC 容器，作为容器, 那么它就具备两个最基础的功能：存和取，我们把对象交由 Spring 管理, 由 Spring 来负责对象的创建和销毁. 我们程序只需要告诉 Spring , 哪些对象需要存, 以及如何从中取出对象，Spring 容器管理的对象, 我们称之为 “Bean”.。

1. @Repository：用于 DAO 层，将数据访问层的实现类标记为 Spring 管理的 Bean。
2. @Service：用于 Service 层，将业务逻辑层的实现类标记为 Spring 管理的 Bean。
3. @Controller：用于控制器层，通常处理 HTTP 请求，并将其标记为 Spring 管理的 Bean。

在 Controller 层 和 Service 层注入运行时依赖的对象: 使用注解 @Autowired

讯享网

1.5.1 Bean 的存储

而 Spring 框架为了更好的服务 web 应用程序, 提供了更丰富的注解.

1. 类注解：@Controller、@Service、@Repository、@Component、@Configuration.
2. 方法注解：@Bean.

接下来我们分别来看

1.5.1.1 @Controller（ 控制器存储 ）

使用 @Controller 存储 bean 的代码如下所示：

如何观察这个对象已经存在 Spring 容器当中了呢，接下来我们学习如何从 Spring 容器中获取对象

讯享网

观察运行结果, 发现成功从 Spring 中获取到 Controller 对象, 并执行 Controller 的 sayHi 方法

如果把 @Controller 删掉, 就会报错，因为这个对象没有存储到 bean 中。

1.5.1.2 获取 bean 对象的其他方式

程序开发人员不需要为 bean 指定名称, 如果没有显式的提供名称， Spring 容器将为该 bean 生成唯⼀的名称，命名约定 bean 名称以小写字母开头，然后使用驼峰式写法大小写.

比如：

• 类名: UserController, Bean的名称为: userController
• 类名: AccountManager, Bean的名称为: accountManager
• 类名: AccountService, Bean的名称为: accountService

也有⼀些特殊情况, 当有多个字符并且第⼀个和第⼆个字符都是大写时, 将保留原始的大小写，比如

• 类名: UController, Bean的名称为: UController
• 类名: AManager, Bean的名称为: AManager

根据这个命名规则, 我们来获取Bean.

运行结果可以看出地址⼀样, 说明对象是⼀个

1.5.1.4 @Service（ 服务存储 ）

使用 @Service 存储 bean 的代码如下所示：

讯享网

读取代码不变，这里跳过

1.5.1.5 @Repository（ 仓库存储 ）

使⽤ @Repository 存储 bean 的代码如下所示：

1.5.1.6 @Component（ 组件存储 ）

使⽤ @Component 存储 bean 的代码如下所示：

讯享网

1.5.1.7 @Configuration（ 配置存储 ）

使用 @Configuration 存储 bean 的代码如下所示：

这个也是和咱们前面讲的应用分层是呼应的. 让程序员看到类注解之后，就能直接了解当前类的用途.

• @Controller：控制层, 接收请求, 对请求进行处理, 并进行响应.
• @Servie：业务逻辑层, 处理具体的业务逻辑.
• @Repository：数据访问层，也称为持久层. 负责数据访问操作
• @Configuration：配置层. 处理项目中的⼀些配置信息.

程序的应用分层，调用流程如下：

类注解之间的关系：查看 @Controller / @Service / @Repository / @Configuration 等注解的源码发现

其实这些注解里面都有⼀个注解 @Component ，说明它们本身就是属于 @Component 的 “子类”