Spring 5.0.0框架介绍_中文版_3.9

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spring 5.0.0框架介绍_中文版_3.9相关的知识,希望对你有一定的参考价值。

参考技术A

基于注解的配置提供了一种XML设置的可替代方式,它依赖于字节码元数据来连接组件,而不是用尖括号声明的方式。代替使用XML来描述bean连接,开发者通过将注解使用在相关的类,方法或字段声明中,将配置移动到了组件类本身的内部。正如在“Example: The RequiredAnnotationBeanPostProcessor”那节提到的那样,使用 BeanPostProcessor 与注解结合是扩展Spring IoC容器的的常见方法。例如,Spring 2.0引入了 @Required 注解来执行需要的属性的可能性。Spring 2.5使以同样地通用方法来驱动Spring的依赖注入变为可能。本质上来说, @Autowired 提供了如3.4.5小节描述的同样的能力。“Autowiring collaborators”但更细粒度的控制和更广的应用性。Spring 2.5也添加对JSR-250注解的支持,例如, @PostConstruct 和 @PreDestroy
。Spring 3.0添加了对JSR-330,包含在 javax.inject 包内的注解(Java的依赖注入)的支持,例如 @Inject 和 @Named 。关于这些注解的细节可以在相关的小节找到。

跟以前一样,你可以作为单独的bean定义来注册它们,但也可以通过在一个基于XML的Spring配置(注入包含上下文命名空间)中包含下面的标签来隐式的注册它们:

(隐式注册的后处理器包括 AutowiredAnnotationBeanPostProcessor , CommonAnnotationBeanPostProcessor , PersistenceAnnotationBeanPostProcessor 和前面提到的 RequiredAnnotationBeanPostProcessor 。)

@Required 注解应用到bean属性的setter方法上,例子如下:

这个注解仅仅是表明受影响的bean属性必须在配置时通过显式的bean定义或自动组装填充。如果受影响的bean属性没有填充,容器会抛出一个异常,这允许及早明确的失败,避免 NullPointerExceptions 或后面出现类似的情况。仍然建议你在bean类本身加入断言,例如,加入到初始化方法中。这样做可以强制这些需要的引用和值,甚至是你在容器外部使用这个类的时候。

你可以将 @Autowired 注解应用到构造函数上。

正如预料的那样,你也可以将 @Autowired 注解应用到“传统的”setter方法上:

你也可以应用注解到具有任何名字和/或多个参数的方法上:

你也可以应用 @Autowired 到字段上,甚至可以与构造函数混合用:

通过给带有数组的字段或方法添加 @Autowired 注解,也可以从 ApplicationContext 中提供一组特定类型的bean:

同样也可以应用到具有同一类型的集合上:

只要期望的key是 String ,那么类型化的Maps就可以自动组装。Map的值将包含所有期望类型的beans,key将包含对应的bean名字:

默认情况下,当没有候选beans可获得时,自动组装会失败;默认的行为是将注解的方法,构造函数和字段看作指明了需要的依赖。这个行为也可以通过下面的方式去改变。

你也可以对那些已知的具有可解析依赖的接口使用 @Autowired : BeanFactory , ApplicationContext , Environment , ResourceLoader , ApplicationEventPublisher 和 MessageSource 。这些接口和它们的扩展接口,例如 ConfigurableApplicationContext 或 ResourcePatternResolver ,可以自动解析,不需要特别的设置。

因为根据类型的自动装配可能会导致多个候选目标,所以在选择过程中进行更多的控制经常是有必要的。一种方式通过Spring的 @Primary 注解来完成。当有个多个候选bean要组装到一个单值的依赖时, @Primary 表明指定的bean应该具有更高的优先级。如果确定一个\'primary\' bean位于候选目标中间,它将是那个自动装配的值。

假设我们具有如下配置,将 firstMovieCatalog 定义为主要的 MovieCatalog 。

根据这样的配置,下面的 MovieRecommender 将用 firstMovieCatalog 进行自动装配。

对应的bean定义如下:

当有多个实例需要确定一个主要的候选对象时, @Primary 是一种按类型自动装配的有效方式。当需要在选择过程中进行更多的控制时,可以使用Spring的 @Qualifier 注解。为了给每个选择一个特定的bean,你可以将限定符的值与特定的参数联系在一起,减少类型匹配集合。在最简单的情况下,这是一个纯描述性值:

@Qualifier 注解也可以指定单个构造函数参数或方法参数:

对应的bean定义如下。限定符值为"main"的bean被组装到有相同值的构造函数参数中。

对于回退匹配,bean名字被认为是默认的限定符值。因此你可以定义一个id为 main 的bean来代替内嵌的限定符元素,会有同样的匹配结果。然而,尽管你可以使用这个约定根据名字引用特定的beans,但是 @Autowired 从根本上来讲是使用可选的语义限定符来进行类型驱动注入的。这意味着限定符的值,即使回退到bean名称,总是缩小语义类型匹配的集合;它们没有从语义上将一个引用表达为一个唯一的bean id。好的限定符值是"main"或"EMEA"或"persistent",表达一个特定组件的性质,这个组件是独立于bean id 的,即使前面例子中像这个bean一样的匿名bean会自动生成id。

正如前面讨论的那样,限定符也可以应用到类型结合上,例如, Set<MovieCatalog> 。在这个例子中,根据声明的限定符匹配的所有beans作为一个集合进行注入。这意味着限定符不必是唯一的;它们只是构成过滤标准。例如,你可以定义多个具有同样限定符值"action"的 MovieCatalog ,所有的这些都将注入到带有注解 @Qualifier("action") 的 Set<MovieCatalog> 中。

你可以创建自己的定制限定符注解。简单定义一个注解,在你自己的定义中提供 @Qualifier 注解:

然后你可以在自动装配的字段和参数上提供定制的限定符:

接下来,提供候选bean定义的信息。你可以添加 <qualifier/> 标记作为 <bean/> 标记的子元素,然后指定匹配你的定制限定符注解的类型和值。类型用来匹配注解的全限定类名称。或者,如果没有名称冲突的风险,为了方便,你可以使用简写的类名称。下面的例子证实了这些方法。

在3.10小节,“类路径扫描和管理组件”中,你将看到一个基于注解的替代方法,在XML中提供限定符元数据。特别地,看3.10.8小节,“用注解提供限定符元数据”。

在某些情况下,使用没有值的注解就是足够的。当注解为了通用的目的时,这是非常有用的,可以应用到跨几个不同类型的依赖上。例如,当网络不可用时,你可以提供一个要搜索的离线目录。首先定义一个简单的注解:

然后将注解添加到要自动装配的字段或属性上:

现在bean定义只需要一个限定符类型:

你也可以定义接收命名属性之外的定制限定符注解或代替简单的值属性。如果要注入的字段或参数指定了多个属性值,bean定义必须匹配所有的属性值才会被认为是一个可自动装配的候选目标。作为一个例子,考虑下面的注解定义:

这种情况下 Format 是枚举类型:

要自动装配的字段使用定制限定符进行注解,并且包含了两个属性值: genre 和 format 。

最后,bean定义应该包含匹配的限定符值。这个例子也证实了bean元属性可以用来代替 <qualifier/> 子元素。如果可获得 <qualifier/> ,它和它的属性优先级更高,如果当前没有限定符,自动装配机制会将 <meta/> 内的值作为备用,正如下面的例子中的最后两个bean定义。

除了 @Qualifier 注解外,也可以使用Java的泛型类型作为限定符的一种暗示方式。例如,假设你有如下配置:

假设上面的beans实现了一个泛型接口,例如, Store<String> 和 Store<Integer> ,你可以 @Autowire Store 接口,泛型将作为限定符使用:

当自动装配 Lists , Maps 和 Arrays 时,也会应用泛型限定符:

CustomAutowireConfigurer 是一个能使你注册自己的定制限定符注解类型的 BeanFactoryPostProcessor ,即使它们不使用Spring的 @Qualifier 注解进行注解。

AutowireCandidateResolver 通过下面的方式决定自动装配的候选目标:

当多个beans符合条件成为自动装配的候选目标时,"primary" bean的决定如下:如果在候选目标中某个确定的bean中的 primary 特性被设为 true ,它将被选为目标bean。

Spring也支持使用JSR-250 @Resource 对字段或bean属性setter方法进行注入。这是在Java EE 5和6中的一种通用模式,例如在JSF 1.2管理的beans或JAX-WS 2.0的端点。Spring对它管理的对象也支持这种模式。

@Resource 采用名字属性,默认情况下Spring将名字值作为要注入的bean的名字。换句话说,它遵循 by-name 语义,下面的例子证实了这一点:

如果没有显式的指定名字,默认名字从字段名或setter方法中取得。在字段情况下,它采用字段名称;在setter方法情况下,它采用bean的属性名。因此下面的例子将名字为 movieFinder 的bean注入到它的setter方法中:

在 @Resource 特有的没有显式名字指定的情况下,类似于 @Autowired , @Resource 会进行主要的匹配类型来代替指定名字的bean并解析已知的可解析依赖: BeanFactory , ApplicationContext , ResourceLoader , ApplicationEventPublisher 和 MessageSource 接口。

因此在下面的例子中, customerPreferenceDao 字段首先查找名字为 customerPreferenceDao 的bean,然后回退到主要的类型为 CustomerPreferenceDao 的类型匹配。"context"字段会注入基于已知的可解析依赖类型 ApplicationContext 。

CommonAnnotationBeanPostProcessor 不仅识别 @Resource 注解,而且识别JSR-250生命周期注解。在Spring 2.5引入了对这些注解的支持,也提供了在初始化回调函数和销毁回调函数中描述的那些注解的一种可替代方式。假设 CommonAnnotationBeanPostProcessor 在Spring的 ApplicationContext 中注册,执行这些注解的方法在生命周期的同一点被调用,作为对应的Spring生命周期接口方法或显式声明的回调方法。在下面的例子中,缓存会预先放置接近初始化之前,并在销毁之前清除。

Spring6| Spring启示录Spring概述

目录

一:Spring启示录

1. OCP开闭原则

2. 依赖倒置原则DIP

3. 控制反转IoC

二:Spring概述

1. Spring简介

2. Spring8大模块

3. Spring特点


一:Spring启示录

引言:前面我们已经学习了三层架构:表示层、业务层、持久层;表示层调业务层、业务层调持久层;下面我们来写一段代码分析一下缺陷!

表示层:发出请求,调用业务层

package com.powernode.oa.controller;

import com.powernode.oa.service.UserService;
import com.powernode.oa.service.impl.UserServiceImpl;

public class UserController 
    // 调用业务层
    private UserService userService = new UserServiceImpl();

    public void login()
        String username = "admin";
        String password = "******";
        boolean success = userService.login(username, password);
        if (success) 
            // 登录成功
         else 
            // 登录失败
        
    

业务层:编写业务逻辑,调用持久层

注:先编写一个接口UserService,然后用类UserServiceImpl实现这个接口,面向抽象编程

package com.powernode.oa.service.impl;

import com.powernode.oa.bean.User;
import com.powernode.oa.dao.UserDao;
import com.powernode.oa.dao.impl.UserDaoImplForMySQL;
import com.powernode.oa.service.UserService;

public class UserServiceImpl implements UserService 
    // 调用持久层
    private UserDao userDao = new UserDaoImplForMySQL();

    public boolean login(String username, String password) 
        User user = userDao.selectByUsernameAndPassword(username, password);
        if (user != null) 
            return true;
        
        return false;
    

持久层:用来与数据库交互

注:编写一个接口UserDaoImpl,然后用类UserDaoImplForMySQL实现这个接口,面向抽象编程

package com.powernode.oa.dao.impl;

import com.powernode.oa.bean.User;
import com.powernode.oa.dao.UserDao;

public class UserDaoImplForMySQL implements UserDao 
    public User selectByUsernameAndPassword(String username, String password) 
        // 连接MySQL数据库,根据用户名和密码查询用户信息
        return null;
    

从上面可以看出,UserDaoImplForMySQL中主要是连接MySQL数据库进行操作。如果更换到Oracle数据库上,则需要再提供一个UserDaoImplForOracle,这就是对功能的扩展!但是添加了一个新的类UserDaoImplForOracle来应付数据库的变化,这个变化会引起连锁反应;如果想要切换到Oracle数据库上,UserServiceImpl类代码就需要修改:

1. OCP开闭原则

①这样一来就违背了开闭原则OCP!

开闭原则:在软件开发过程中应当对扩展开放对修改关闭。也就是说,如果在进行功能扩展的时候,添加额外的类是没问题的,但因为功能扩展而修改之前运行正常的程序,是不被允许的。因为一旦修改之前运行正常的程序,就会导致项目整体要进行全方位的重新测试,这是相当麻烦的过程!

导致以上问题的主要原因是:代码和代码之间的耦合度太高;如下图所示:

可以很明显的看出,上层是依赖下层的。UserController依赖UserServiceImpl,而UserServiceImpl依赖UserDaoImplForMySQL,这样就会导致下面只要改动上面必然会受牵连(跟着也会改,这样也就同时违背了另一个开发原则:依赖倒置原则(DIP)!

2. 依赖倒置原则DIP

依赖倒置原则(Dependence Inversion Principle),简称DIP:主要倡导面向抽象编程,面向接口编程,不要面向具体编程,让上层不再依赖下层,下面改动了,上面的代码不会受到牵连。这样可以大大降低程序的耦合度,耦合度低了,扩展力就强了,同时代码复用性也会增强。(软件七大开发原则都是在为解耦合服务

思考:但是我们已经先定义接口,然后类实现接口,已经面向接口编程了啊?

确实已经面向接口编程了,但对象的创建是:new UserDaoImplForOracle()显然并没有完全面向接口编程,还是使用到了具体的接口实现类

什么叫做完全面向接口编程?什么叫做完全符合依赖倒置原则呢?请看以下代码:

(1)如果代码是这样编写的,才算是完全面向接口编程,才符合依赖倒置原则!

(2)但是这样userDao是null,在执行的时候就会出现空指针异常;确实是这样的,所以我们要解决这个问题。解决空指针异常的问题,其实就是解决两个核心的问题:

第一个问题:谁来负责对象的创建?【也就是说谁来:new UserDaoImplForOracle()/new UserDaoImplForMySQL()】

第二个问题:谁来负责把创建的对象赋到这个属性上?【也就是说谁来把上面创建的对象赋给userDao属性】

如果把以上两个核心问题解决了,就可以做到既符合OCP开闭原则,又符合依赖倒置原则!

幸运的是Spring框架可以做到,在Spring框架中,它可以帮助我们new对象,并且它还可以将new出来的对象赋到属性上。换句话说,Spring框架可以帮助我们创建对象,并且可以帮助我们维护对象和对象之间的关系。比如:

Spring既可以new出来UserDaoImplForMySQL对象,也可以new出来UserDaoImplForOracle对象,并且还可以让new出来的dao对象和service对象产生关系(产生关系其实本质上就是给属性赋值)。很显然,这种方式是将对象的创建权/管理权交出去了,不再使用硬编码的方式了;像这种把对象的创建权/管理权交出去了,被称为控制反转(IoC)

3. 控制反转IoC

控制反转(Inversion of Control,缩写为IoC):是面向对象编程中的一种设计思想,可以用来降低代码之间的耦合度,符合依赖倒置原则。

反转的是两件事:
①第一件事:我不在程序中采用硬编码的方式来new对象了。(new对象我不管了,new对象的权利交出去了)
②第二件事:我不在程序中采用硬编码的方式来维护对象的关系了。(对象之间关系的维护权,我也不管了,交出去了)

控制反转的核心是:将对象的创建权交出去、将对象和对象之间关系的管理权交出去,由第三方容器来负责创建与维护!

控制反转常见的实现方式:依赖注入(Dependency Injection,简称DI)通常,依赖注入的实现由包括两种方式:

①set方法注入(执行set方法给属性赋值)

②构造方法注入(执行构造方法给属性赋值)

依赖注入 中 “依赖”是什么意思? “注入”是什么意思?
①依赖:A对象和B对象的关系。
②注入:是一种手段,通过这种手段,可以让A对象和B对象产生关系。
③依赖注入:对象A和对象B之间的关系,靠注入的手段来维护;而注入包括set注入和构造注入。

注:控制反转是思想,依赖注入是这种思想的具体实现方式!

Spring框架就是一个实现了IoC思想的框架。IoC可以认为是一种全新的设计模式,但是理论和时间成熟相对较晚,并没有包含在GoF中。(GoF指的是23种设计模式)

总结术语:
①OCP:开闭原则(开发原则)
②DIP:依赖倒置原则(开发原则)
③IoC:控制反转(一种思想,一种新型的设计模式)
④DI:依赖注入(控制反转思想的具体实现方式)

二:Spring概述

1. Spring简介

官网地址https://spring.io/

Spring是一个开源框架,它由Rod Johnson创建。它是为了解决企业应用开发的复杂性而创建的。从简单性、可测试性和松耦合的角度而言,任何Java应用都可以从Spring中受益。

①Spring是一个轻量级的控制反转(IoC)和面向切面(AOP)的容器框架。

②Spring最初的出现是为了解决EJB臃肿的设计,以及难以测试等问题。

③Spring为简化开发而生,让程序员只需关注核心业务的实现,尽可能的不再关注非业务逻辑代码(事务控制,安全日志等)。

2. Spring8大模块

注意:Spring5版本之后是8个模块,在Spring5中新增了WebFlux模块。Spring的两大核心模块:控制反转(IoC)面向切面(AOP),面向切面(AOP)底层的实现也是基于控制反转(IoC)的,其它模块也都用到了AOP+IoC!

①Spring Core模块

这是Spring框架最基础的部分,它提供了依赖注入(DependencyInjection)特征来实现容器对Bean的管理。核心容器的主要组件是 BeanFactory,BeanFactory是工厂模式的一个实现,是任何Spring应用的核心。它使用IoC将应用配置和依赖从实际的应用代码中分离出来。

②Spring Context模块

如果说核心模块中的BeanFactory使Spring成为容器的话,那么上下文模块就是Spring成为框架的原因。这个模块扩展了BeanFactory,增加了对国际化(I18N)消息、事件传播、验证的支持。另外提供了许多企业服务,例如电子邮件、JNDI访问、EJB集成、远程以及时序调度(scheduling)服务。也包括了对模版框架例如Velocity和FreeMarker集成的支持

③Spring AOP模块

Spring在它的AOP模块中提供了对面向切面编程的丰富支持,Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP,不用依赖组件,就可以将声明性事务管理集成到应用程序中,可以自定义拦截器、切点、日志等操作。

④Spring DAO模块

提供了一个JDBC的抽象层和异常层次结构,消除了烦琐的JDBC编码和数据库厂商特有的错误代码解析,用于简化JDBC。

⑤Spring ORM模块

Spring提供了ORM模块。Spring并不试图实现它自己的ORM解决方案,而是为几种流行的ORM框架提供了集成方案,包括Hibernate、JDO和iBATIS SQL映射,这些都遵从 Spring 的通用事务和 DAO 异常层次结构。

⑥Spring Web MVC模块

Spring为构建Web应用内置提供了一个功能全面的MVC框架。虽然Spring可以很容易地与其它MVC框架集成,例如Struts,但Spring的MVC框架使用IoC对控制逻辑和业务对象提供了完全的分离。

⑦Spring Web模块

Web 上下文模块建立在应用程序上下文模块之上,为基于 Web 的应用程序提供了上下文,提供了Spring和其它Web框架的集成,比如Struts、WebWork。还提供了一些面向服务支持,例如:实现文件上传的multipart请求。

⑧Spring WebFlux模块

Spring Framework 中包含的原始 Web 框架 Spring Web MVC 是专门为 Servlet API 和 Servlet 容器构建的。反应式堆栈 Web 框架 Spring WebFlux 是在 5.0 版的后期添加的;它是完全非阻塞的,支持反应式流(Reactive Stream)背压,并在Netty,Undertow和Servlet 3.1+容器等服务器上运行。

3. Spring特点

①轻量

①从大小与开销两方面而言Spring都是轻量的;完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布;并且Spring所需的处理开销也是微不足道的。

②Spring是非侵入式的:Spring应用中的对象不依赖于Spring的特定类。

②控制反转

Spring通过一种称作控制反转(IoC)的技术促进了松耦合。当应用了IoC,一个对象依赖的其它对象会通过被动的方式传递进来,而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反——不是对象从容器中查找依赖,而是容器在对象初始化时不等对象请求就主动将依赖传递给它。

注:JNDI是Java命名和目录接口是Java编程语言中接口的名称(JNDI)。它是一个API(应用程序接口)

③面向切面

Spring提供了面向切面编程的丰富支持,允许通过分离应用的业务逻辑与系统级服务(例如审计(auditing)和事务(transaction)管理)进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责(甚至是意识)其它的系统级关注点,例如日志或事务支持。

④容器

Spring包含并管理应用对象的配置和生命周期,在这个意义上它是一种容器,你可以配置你的每个bean如何被创建——基于一个可配置原型(prototype),你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例——以及它们是如何相互关联的。然而,Spring不应该被混同于传统的重量级的EJB容器,它们经常是庞大与笨重的,难以使用。

⑤框架

Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中,应用对象被声明式地组合,典型地是在一个XML文件里。Spring也提供了很多基础功能(事务管理、持久化框架集成等等),将应用逻辑的开发留给了你。

所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码;它们也为Spring中的各种模块提供了基础支持。

注:Spring6要求JDK最低版本是Java17!

以上是关于Spring 5.0.0框架介绍_中文版_3.9的主要内容,如果未能解决你的问题,请参考以下文章

spring_01

[刘阳Java]_Spring入门_第1讲

[刘阳Java]_Spring相关配置介绍_第5讲

SpringBoot脚手架项目001__项目介绍技术介绍

Java大数据开发工程师__Spring学习笔记(待更新)

[刘阳Java]_Spring整合Servlet补充_第14讲