Spring框架起步，小白都看得懂（官翻版）！

写在开头

本篇章介绍Spring框架的完整地所有技术。

本人偏心Java Configuration(也是Spring推荐的方式)，因此一样配置的状况下，将略去XML配置不表，请知悉。

官翻版本：Spring Framework Core 5.2.5.RELEASE

本文会尽可能遵照原文排版，因此某些我以为不过重要的，我会只加标题，而不加具体内容，并放上连接，供感兴趣的读者自行阅读。

由于考虑到考研，项目开发等，因此文章更新会慢一些，若是你喜欢的话，也能够私信我提醒更新！

须要的基础知识：

Java SE(Version 11.0+)
Maven(Version 3.62+)
JetBrains IntelliJ IDEA(Version 2019.3.4+)
GitHub
复制代码

出现的专业词汇讲解

配置元数据：配置源或配置文件的意思。

依赖：顾名思义，构建某个实例须要的其余实例，由于依赖于这个实例，因此叫“依赖”。

Bean：中文翻译“豆子，黄豆”，就是一个类实例，只是这个类只有getter/setter方法和私有域而已，常做为数据载体。

DAO: 数据库访问类(Data Access Object)，就是一类专门用来访问数据库的Bean

耦合：依赖的意思，A和B耦合性越高，说明它俩互相依赖性越强，离开谁另外一个都不行，软件设计讲究低耦合，是为了后期维护方便，省得“牵一发而动全身”。

属性(Property)：属性，其实就是私有域。

绪论

在Spring Framework中，最重要的莫过于Spring Framework的Inversion Of Control(IOC)控制反转。本文会先介绍IOC技术，以后是完整且全面的Spring Framework Aspect-Oriented Programming(AOP)面向切面编程。从概念上说，Spring的AOP是很好理解的，同时它也能够解决企业编程的80%的AOP问题。

Spring整合了AspectJ(一个当前特性最丰富，最成熟的Java企业级AOP实现)。(暗示Spring的AOP很牛逼)

IOC容器

Spring IOC容器和Bean介绍

IOC也做为Dependency Injection(DI)依赖注入而被人知晓。它是一个定义对象依赖的过程，对象从构造参数，工厂方法参数，属性值获取建立此对象须要的依赖(其实就是其余对象)。

容器就有点秀了！它在对象须要依赖时(须要其余对象时)主动地注入进去，这个过程本质上经过直接构造类或者相似服务定位模式的机制来取代bean实现对于依赖的实例化或定位过程，“接管了”对象对于依赖的控制，就像“反转同样”，因此叫控制反转(Inversion of Control)。

org.springframework.beans和org.springframework.context这两个包是Spring Framework IOC容器的基础包，其中：BeanFactory接口提供了一种高级配置机制，这种机制能够管理任何类型的对象。ApplicationContext是它的一个子接口，它拥有：

a)更简单地整合Spring AOP特性。
b)管理资源处理。
c)发布事件。
d)应用层次的特殊上下文(context)，好比在Web应用中的WebApplicationContext。
复制代码

简而言之，BeanFactory提供了配置框架和基础功能，ApplicationContext添加一些企业开发方面的功能。Application是BeanFactory的一个彻底的超集，本章仅仅用它来描述Spring IOC容器，想要了解更多关于BeanFactory，详见这里

在Spring里，构成你应用骨干的对象实例被称为“bean”，bean是啥呢？是一个实例化了的，组装了的，同时被Spring IOC容器管理的对象。bean仅仅是你应用中的众多对象之一。全部的Bean以及他们所使用的依赖，都被容器使用配置元数据利用反射管理着。

容器概览

org.springframework.ApplicationContext接口表明了Spring IOC容器，它负责实例化，配置和装配bean。容器经过读取配置元数据来决定对哪一个对象进行实例化，配置，和装配。元数据以XML, Java注解或Java代码形式。它让你能够清楚地指明构成你应用的对象，以及它们之间丰富的内部依赖关系。

下图展现了Spring是怎么工做的：

配置元数据

正如图所示的那样，Spring IOC容器使用一个配置元数据构成的表单。这个含有配置元数据的表单，表明着你，也就是此应用的开发者，但愿Spring容器应该怎样实例化，配置和装配你应用中的Bean组件。

传统的设置配置元数据的方法是使用简单直观明了的XML形式，这也是本章主要的配置方法。

P.s.
XML并非惟一的格式，Spring IOC容器已经从之解耦出来了，当下，愈来愈多的开发者使用基于Java注解的配置方法(好比我)。
复制代码

想要了解更对其余配置格式？

*基于注解的配置(Spring 2.5引入)

*基于Java的配置(Spring 3.0引入，一些由Spring JavaConfig提供的特性逐渐成了Spring Framework的核心，因此你可使用Java配置为你的应用提供外部Bean而不是使用XML文件，想使用这些新特性？试试@Configuration, @Bean, @Import, @DependsOn)

Spring配置考虑到容器至少管理一个(一般不少个)Bean定义，Java配置在@Configuration注解修饰的类里面使用@Bean注解来完成定义这些Bean。

这些Bean定义与实例对象联系起来而后修饰你的应用。一般状况下，你会定义业务层对象，好比数据库访问对象(DAO. Data Access Object)，表示对象，例如Struts Action实例，基础结构对象，例如Hibernate SessionFactories，JMS队列，诸如此类。通常来讲，加载域对象是DAO或业务逻辑的职责，因此容器里面不会有细粒化的域对象。不过，你可使用Spring对于AspectJ的整合来配置IOC容器控制以外建立的对象。详见。

简单用法：

public class Book {
    // ...
}

@Configuration
public class WebConfig {
    // ...
    @Bean(name = "book")
    public Book book() {
        return new Book();
    }
}
复制代码

若须要在某个配置类引用其余的配置类，能够在类前面加上：

@Import(value = {ConfigA.class, ConfigB.class})
复制代码

使用容器

经过使用：

T getBean(String name, Class<T> requiredType) 复制代码

方法，能够获取Bean实例。

可是，理想状况下，你不该该使用getBean()方法，由于这会破坏容器对于对象的自动管理，你可使用诸如@Autowired的注解来在特殊Bean里面获取你须要的依赖。(说白了，别有事没事调用getBean()，测试除外，那否则，你还有IOC容器帮你管理干啥？直接本身整呗！弟弟！)

Bean概览

在IOC容器里面，Bean的定义以BeanDefinition的形式呈现。它们包含如下的元数据：

a)包限定名的类，包含了Bean的实现类。
b)Bean行为定义组件，定义了Bean在IOC容器里面的行为。
c)对于此Bean须要的其余Bean的引用，这些引用又被称为“合做者”或“依赖”。
d)其余用于设置新建立的Bean的配置，好比超时时间，数据库链接池数量等。
复制代码

元数据被传递到一个配置集合中，以用来表达Bean定义。

具体的Bean配置集合，详见。

ApplicationContext还容许用户在容器外面自定义Bean。经过ApplicationContext的getBeanFactory()方法获取，此方法返回BeanFactory的DefaultListableBeanFactory实现，DefaultListableBeanFactory支持经过registerSingleton(..)和registerBeanDefinition(..)来注册Bean。不过，一般状况下，应用只能和经过配置元数据定义的Bean协做。

命名Bean

一个Bean一般含有一个或多个惟一标识符。若是不指出bean名字，就会使用默认名(类名首字母小写)，bean命名遵照Java命名规范，首字母小写+驼峰命名。固然还可使用别名(说真的，通常没用过)。

实例化Bean

对于XML，应该指出(强制地)其类型。在这种方式下，能够经过调用类的构造器建立，等同于new一个实例；还能够调用静态的工厂方法来建立。使用构造器建立时，容器会本身寻找构造器，因此你就只须要像编写普通类那样就好，这里指出，最好有一个无参构造器。

Spring容器不只仅能够管理实体类，虚拟类也能够被其管理，好比，不符合Java Bean规范的数据库链接池。

对于XML配置，使用静态工厂方法时，class指出工厂类，factory-method指出具体的静态方法。如果使用实例工厂方法，把class属性换成factory-bean并指向工厂类就好。

依赖

典型的企业级应用一般不会包含单例对象，即便是最小的应用，它的某个对象也须要别的对象的嵌入才能运行。本节介绍如何经过定义Bean配置来实现把单个的对象组织起来，实现彻底解耦合的应用。

依赖注入

Dependency Injection依赖注入(DI)指的是这样的一个过程：对象只能经过构造器参数，工厂方法参数，在对象实例被构造以后的属性值或工厂方法的返回值来定义它们的依赖。容器在建立这些Bean时主动注入这些依赖，这个过程称为对于Bean本身控制依赖的获取，定位这一职责的反转。

归功于DI的存在，代码更加简洁明了，解耦更加高效。Bean不在主动引入他们须要的依赖，因此测试更加容易。介于某些Bean是接口的实现类，因此抹除某些特性并加入新的来测试，模拟都变得那么简单！

1. 基于构造器的DI

基于构造器的DI，由容器调用无参或有参构造器完成。调用静态工厂方法也能够起到相同的效果，如下展现一个构造器注入的例子：

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on a MovieFinder
    private MovieFinder movieFinder;

    // a constructor so that the Spring container can inject a MovieFinder
    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}
复制代码

2. 解析构造参数

这玩意属于XML的了，说白了就是，构造器参数匹配顺序出现歧义时，应显式地指明顺序。在Java Configuration里面，直接@Autowired就完事了，整这么多记不住的！

3. 基于setter的DI

容器在调用过你的无参构造器或无参静态工厂方法后，调用你的setter方法完成依赖注入。来个例子看看：

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;

    // a setter method so that the Spring container can inject a MovieFinder
    public void setMovieFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}
复制代码

除了以上两种注入，ApplicationContext还支持在构造器注入以后再次经过调用setter进行注入。

构造器注入和setter注入比较：

在setter方法上使用@Required注解可使此属性成为必须注入的依赖。带有参数验证的控制器注入是更好的选择。

Spring 团队建议使用构造器注入，这样能够更大程度上减小组件构建时参数变化带来的风险，以及非空断定。长远角度来讲，此方法构建的Bean一般是初始化状态的完美Bean。过多的构造参数，可能说明你的代码写得太垃圾了，重构吧！少年！

setter方法注入，通常适用于可选依赖，这种依赖通常能够被指定一个默认值，可是，仍是得注意对于它的非空检查。setter注入的好处在于，后期能够再次配置或注入依赖，增长了变通性。

使用依赖注入，可让第三方对象也更加方便的享受到容器管理的便捷，可是一旦第三方类没有setter方法，就只能经过构造器注入依赖了。

4. 依赖解析过程

容器进行依赖解析过程以下：

a)经过配置元数据(好比xml文件，Java代码，注解)来建立和初始化ApplicationContext。
b)对于每一个Bean，它的依赖项都以属性，构造器参数，静态工厂方法参数呈现出来，当Bean被建立时，依赖会自动添加进去。
c)每个属性或构造器参数，都是容器里面的一个对于其余Bean的引用，或准备设置的值的实际定义。
d)每个属性或构造器参数的值，都是从特殊类型转换到属性或构造器参数的实际类型以后的值。默认状况下，Spring能够把String类型的值转换成八大基本类型。
复制代码

在容器建立时，Spring会验证每一个Bean配置的合法性，Bean属性在Bean被建立以前，一直不会被设置。单例和预建立的Bean会在容器建立时一同被建立，其他状况均为须要建立时才会建立，由于每次建立都会引起连锁反应(Bean的依赖被建立，以来的依赖被建立...)，因此对于不匹配的解析可能会在稍后出现。

注意避免循环依赖，好比A依赖B，B依赖C，C依赖A。对于这个种状况，要注意避免，好比经过基于setter的DI来下降依赖。

Spring容器会在加载期间推断潜在的问题(好比空指针，循环引用)。Spring尽量迟地设置属性，这代表，可能一开始建立Bean正常，但过会就会抛异常。这也就是为何ApplicationContext使用预建立做为默认方式的缘由。在ApplicationContext建立时，以时间和内存换取更加可靠地系统(发现更多潜在的问题)，而不是在须要建立时才发现问题，正是Spring采起的方式。固然，你能够覆写这个策略，实现单例建立(尽量迟地建立)。

若是啥问题也么得，Spring就会开始注入Bean了，此时Spring会提早配置好须要建立的Bean所须要的依赖。这意味着，若是A须要B，那么Spring可能会在初始化A以后，而后配置B，再而后调用A的setter方法来完成DI。换句话说，一个Bean被建立，而后调用它的setter方法注入依赖，而后相关的生命周期方法会被调用。

5. 依赖注入的例子

XML格式略去不表，相似用@Autowired注入。

依赖和细节配置

正如前面提到的那样，你能够经过引用其余被容器管理着的Bean会内置的值来实现对属性或构造器参数的设置。

1. 直接值

就，字面意思，写在属性标签(<property/>)里面的字符串，可做为属性值进行注入，这属于XML文件了，典型的用法就是MyBatis数据库配置，略过不表。

2. 引用其余的Bean

也是字面意思`，经过引用此容器管理的其余Bean来设置当前Bean的属性。

3. 内部Bean

为了建立此Bean而建立的一个匿名Bean，就像在类里面建立了匿名类同样；没法被容器管理，访问，注入，只是一个生成此Bean的辅助Bean。

4. 集合

集合标签可用于设置Bean的集合类型，常见的集合都可使用。

5. Null和Empty的String值

空字符串就是属性值为""，若不设置属性，属性就为Null。

6. 复合属性名

就也是字面意思，至关于属性的属性，给属性的属性设值。

使用depends-on

能够强制此Bean所使用的依赖在初始化此Bean钱被强制初始化。

<bean id="beanOne" class="ExampleBean" depends-on="manager"/>
<bean id="manager" class="ManagerBean" />

// or
<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
    <property name="manager" ref="manager" />
</bean>

<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />
复制代码

延迟初始化Bean

是一个属性，指出是否延迟初始化。

<bean id="lazy" class="com.something.ExpensiveToCreateBean" lazy-init="true"/>
<bean name="not.lazy" class="com.something.AnotherBean"/>
复制代码

容器级别的延迟：

<beans default-lazy-init="true">
    <!-- no beans will be pre-instantiated... -->
</beans>
复制代码

自动织入协做器

自动织入的优势：

a)大大减小指定属性或构造器参数的须要。
b)当你的应用更新时，自动织入能够更新配置。这个特性，在开发方面很是有用。
复制代码

自动织入有四个模式

a)no: 不开启自动织入，经过引用其余Bean实现引用依赖。
b)byName: 根据属性名自动织入
c)byType: 若是容器存在此属性类型，便织入。
d)constructor: 相似byType，可是只适用于构造器参数。
复制代码

自动织入的局限性和不足:

暂略不表。
复制代码

去除自动织入中的Bean

暂略不表。
复制代码

方法注入

背景：大多时的场景，大多数的Bean都是单例的，当一个单例Bean须要和另外一个单例Bean协做时，或一个非单例Bean须要和另外一个非单例Bean合做时，一般你会经过把某个Bean定义成另外一个(Bean)的属性来处理依赖问题。当Bean生命周期不一致时，嚯嚯，问题来了。假设在A的每一个方法调用上，单例Bean A要使用非单例Bean B。容器只会建立A的实例一次，因此只有一次设置属性B的机会，可是容器可不能在每次须要B的时候都提供一个新的实例啊！这就形成了问题。

解决措施之一是，暂时取消一些IOC，你能够经过实现ApplicationContextAware接口来让A发现容器，并经过调用容器的getBean("B")方法来在每次须要B实例时，获取一个新的实例。来看一个例子：

// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;

// Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class CommandManager implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    public Object process(Map commandState) {
        // grab a new instance of the appropriate Command
        Command command = createCommand();
        // set the state on the (hopefully brand new) Command instance
        command.setState(commandState);
        return command.execute();
    }

    protected Command createCommand() {
        // notice the Spring API dependency!
        return this.applicationContext.getBean("command", Command.class);
    }

    public void setApplicationContext( ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}
复制代码

以上代码耦合到了Spring框架，因此不是很推荐，可是这种方法确实可让你写出干净的处理代码。

下一篇