【Spring】 IoCDI

news2024/9/23 19:19:53

回顾

企业命名规范

大驼峰:BookDao(首字母都大写)	类名
小驼峰:bookDao(第一个字母小写)	方法名
蛇形:book_dao(小写+下划线_)	数据库
串形:book-dao(小写+连字符-)	项目文件夹

各种注解

学习Spring MVC, 其实就是学习各种Web开发需要⽤的到注解

a. @RequestMapping: 路由映射

b. @RequestParam: 后端参数重命名

c. @RequestBody: 接收JSON类型的参数

d. @PathVariable: 接收路径参数

e. @RequestPart: 上传⽂件

f. @ResponseBody: 返回数据

g. @CookieValue: 从Cookie中获取值

h. @SessionAttribute: 从Session中获取值

i. @RequestHeader: 从Header中获取值

j. @Controller: 定义⼀个控制器, Spring 框架启动时加载, 把这个对象交给Spring管理. 默认返回视图.

k. @RestController: @ResponseBody + @Controller 返回数据

好用的工具插件

Java EE学习阶段会涉及较多⼯具, 插件的学习, 来帮助我们提⾼开发效率. ⽐如Postman, lombok, EditStarter, 后⾯还会继续学习其他的⼯具或插件.

一.Spring

Spring两大核心思想

1.IoC

2.AOP

1.IoC控制反转

Inversion of Control 控制反转,Spring是一个控制反转的容器.(spring拥有了创建对象的控制权)

举一个例子来理解什么是控制反转?

我们要造一辆汽车,汽车依赖车身,车身依赖底盘,底盘依赖轮子.

由于层层的依赖关系,程序的耦合度非常高,此时如果我们想改变位于底层的轮胎的大小,或者增加轮胎的属性,整个调用链上的所有代码都需要修改.这当然是是一个问题.

如果我们转变思路:先根据汽车的样子设计车身,再根据车身设计底盘,根据底盘设计轮子. 这个时候,他们的依赖关系就完全倒置了: 轮子依赖底盘,底盘依赖车身,车身依赖汽车.

实现:将所需要的依赖从原来创建下级类的方式改为传递/注入的方式,此时我们不需要关注下级类的属性变化,传递过来的是什么,我们就接受什么,此类本身并不需要修改代码.这也完成了程序的解耦!

IoC方式和传统方式的对比

传统开发对象的创建顺序: Car - FrameWork - Bottom - Tire

改进之后的创建对象顺序:Tire - Bottom - Framework - Car

改进之后的控制权发生了反转,不再是使用方对象创建并控制依赖对象了,而是把依赖对象注入到当前对象中,依赖对象的控制权不再由当前类控制.

这也就是IoC的实现思想.

IoC容器的优点

资源不再由使用双方管理,而是由第三方管理

1.资源集中管理:IoC容器会帮我们管理一些资源对象,需要时,去容器中去取就可以了

2.解耦合:降低了使用资源双方的依赖程度,创建实例的时候不需要了解其中的细节

总结:Spring是一个包含众多工具的IoC容器,来帮助我们做资源管理.

IoC是一种思想,DI是IoC的一种实现方法.

2.DI依赖注入

Dependency Injection依赖注入

容器在运行期间,动态地为应用程序提供运行时所依赖的资源.

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

二.IoC 和 DI 的使用

Spring作为一个IoC容器,它具备两个最基础的功能,那就是存和取;

存和取的其实就是spring容器帮管我们管理的对象,我们把他们称之为Bean.

这些对象交由Spring管理,由Spring来负责对象的创建和销毁.

我们要做的分两步:

1.告诉Spring,哪些需要存	添加@Component注解(例)
2.知道如何从Spring取出对象	添加注解@Autowired

比如:

原本在UserController类中要使用UserDao对象,就需要new出UserDao对象,但是现在我们也可以将UserDao交给Spring管理了, 具体的实现只需要两步 :

1.告诉Spring帮我们管理UserDao

在类上面添加@Component注解

2.从Spring中获取UserDao对象

在对象声明时添加@Autowired注解

Bean的存储

上述IoC容器创建和管理对象的过程也就是bean的存储.

前面我们使用的是@Component注解来把对象交给IoC容器管理,而Spring框架为了更好服务web应用程序,提供了更更富的注解.

1.类注解(五大注解)

@Controller	控制层存储
@Service	服务存储
@Repository	仓库存储
@Component	组件存储
@Configuration	配置存储

1.1@Controller

使用@Controller存储bean:

从Spring上下文中获取bean对象的三种方式:

先获取到Spring上下文,再调用getBean方法.

getBean(Class)

getBean(String s)

这种要强转 .

特殊情形:如果类名前两位都是大写,那么不用变,直接使用原名

getBean(String , Class)

bean名的约定

类名: UserController, Bean的名称为: userController

类名: AccountManager, Bean的名称为: accountManager

类名: AccountService, Bean的名称为: accountService

特殊情况, 当有多个字符并且第⼀个和第⼆个字符都是⼤写时, 将保留原始的⼤⼩写.

⽐如

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

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

1.2@Service

1.3@Repository

1.4@Component

1.5@Configuration

上述四个注解和@Controller也是相同的使用方法.

为什么要这么多注解

其实注解和分层式呼应的.不同的注解对应不同的用途.

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

注解之间的关系

@Controller / @Service / @Repository / @Configuration 这四个注解的源码里都有一个@Component , 说明它们本身就是属于@Component的 " 子类 " ,@Component 是⼀个元注解，@Controller , @Service , @Repository 等. 这些注解被称为 @Component 的衍⽣注解.
@Controller , @Service 和 @Repository ⽤于更具体的⽤例(分别在控制层, 业务逻辑层, 持久化层), 在开发过程中, 如果你要在业务逻辑层使⽤ @Component 或@Service，显然@Service是更好的选择.
只有@controller注解才可以被其他类访问到,这是controller的特殊功能.

ApplicationContext 和 BeanFactory

BeanFactory

获取bean对象其实是父类BeanFactory提供的功能.

它们都是Spring容器的的顶级接口,其实BeanFactory提供了基础的访问容器的能力,ApplicationContext属于BeanFactory的子类,继承了BeanFactory的所有功能,并且还拥有独立的特性,添加了国际化支持/资源访问支持/时间传播

性能:applicationContext是一次性加载并初始化所有Bean对象,而BeanFactory是懒加载,需要用到才会去加载,因此更轻量.