Spring 5 中文解析核心篇-IoC容器之基于Java容器配置@慕课网原创_慕课网

1.12 基于Java容器配置

这个部分涵盖了在你的Java代码中怎样去使用注解配置Spring容器。它包含下面的主题：

1.12.1 基本概念：@Bean和@Configuration

Spring的新Java配置支持中的主要构件是@Configuration注解的类和@Bean注解的方法。

@Bean注解使用表示一个方法实例、配置和实例化Spring IoC容器管理的新对象。这些类似Spring的 XML配置，@Bean注解扮演了元素相同的角色。你可以使用@Bean注解方法替换任何Spring中@Component组件。然而，它们最常与@Configuration一起使用。注解类@Configuration注解表示它的主要目的是bean定义的源。此外，@Configuration类允许通过调用同一类中的其他@Bean方法来定义Bean间的依赖关系。下面最简单的@Configuration例子：

@Configuration
public class AppConfig {

    @Bean
    public MyService myService() {
        return new MyServiceImpl();
    }
}

前面的AppConfig类是与下面的Spring XML定义相等：

<beans>
    <bean id="myService" class="com.acme.services.MyServiceImpl"/>
</beans>

完整的@Configuration与“精简” @Bean模式？

当@Bean方法在类中被声明时，这些类没有被注解@Configuration，它们被称为以“精简”模式进行处理。在@Component或在简单的旧类中声明的Bean方法被认为是“精简版”，其中包含类的主要目的不同，而@Bean方法在那里具有某种优势。例如，服务组件在每个可应用的组件类上通过增加一个附加的@Bean方法暴露管理视图到容器。在这种场景下，@Bean方法是一种通用的工厂方法机制。

不像完整的@Configuration，精简@Bean方法不能声明bean之间的依赖关系。相反，它们对其包含的组件的内部状态以及可能声明的参数(可选)进行操作。因此，此类@Bean方法不应调用其他@Bean方法。每个这样的方法实际上只是一个特定bean引用的工厂方法，没有任何特殊的运行时语义。这里的积极副作用是在运行时不需要应用CGLIB子类，所以在类设计方面没有限制(也就是，包含类可能是final)。

在常见的场景中，@Bean方法是在@Configuration类中声明的，确保总是使用完整模式，因此交叉方法引用被重定向到容器的生命周期管理。这可以防止通过常规Java调用意外调用相同的@Bean方法，这有助于减少在lite模式下操作时难以跟踪的细微错误。备注：在@Configuration类中调用其他@Bean方法会定向到容器的生命周期管理。

@Bean和@Configuration在下面的部分深入讨论。首先，我们会覆盖基于Java注解创建Spring容器的各种方式。

1.12.2 通过使用`AnnotationConfigApplicationContext`初始化Spring容器

以下各节介绍了Spring 3.0中引入的Spring的AnnotationConfigApplicationContext。这个通用的ApplicationContext实现不仅能够接收@Configuration类作为输入，还能够接收普通的@Component类和使用JSR-330元数据注解的类

当@Configuration类作为输入被提供，@Configuration类自身作为一个bean定义被注册并且所有在类中被@Bean声明的方法也作为bean的定义被注册到容器。

当提供@Component和JSR-330类时，它们被注册为bean定义，并假设DI元数据(如@Autowired或@Inject)在这些类中使用。

简单构造

与实例化ClassPathXmlApplicationContext时将Spring XML文件用作输入的方式几乎相同，实例化AnnotationConfigApplicationContext时可以将@Configuration类用作输入。如下面的示例所示，这允许完全不使用XML来使用Spring容器：

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
    MyService myService = ctx.getBean(MyService.class);
    myService.doStuff();
}

像前面提到的，AnnotationConfigApplicationContext不限于与@Configuration一起使用。任何@Component或JSR-330注解的类作为输入构造是被支持，类似下面例子：

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(MyServiceImpl.class, Dependency1.class, Dependency2.class);
    MyService myService = ctx.getBean(MyService.class);
    myService.doStuff();
}

前面的例子假设MyServiceImpl、Dependency1、和Dependency2使用Spring依赖注入注解例如：@Autowired。

通过使用register(Class<?>…)编程式的构建容器

你可以通过使用无参构造函数实例化AnnotationConfigApplicationContext并且通过使用register()方法配置。当编程地构建AnnotationConfigApplicationContext时，这个方法是特别地有用。下面类中展示怎样去使用：

public static void main(String[] args) {
    AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
    ctx.register(AppConfig.class, OtherConfig.class);
    ctx.register(AdditionalConfig.class);
    ctx.refresh();
    MyService myService = ctx.getBean(MyService.class);
    myService.doStuff();
}

通过scan(String…)扫描激活组件

扫描激活组件，你可以注解你的@Configuration类：

@Configuration
@ComponentScan(basePackages = "com.acme") //1
public class AppConfig  {
    ...
}

这个注解激活组件扫描

经验丰富的Spring用户可能熟悉Spring context 中等效的XML声明：命名空间，类似下面例子：
<beans>
 <context:component-scan base-package="com.acme"/>
</beans>

在前面的例子中，com.acm包被扫描去查找被注解@Component的类，并且这些类作为Spring bean定义被注册在容器中。AnnotationConfigApplicationContext暴露scan(String…)方法提供相同的组件扫描功能，类似下面的例子：

public static void main(String[] args) {
    AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
    ctx.scan("com.acme");
    ctx.refresh();
    MyService myService = ctx.getBean(MyService.class);
}

记住@Configuration类是使用@Component元注解的，因此它们是组件扫描的候选者。在前面的例子中，假设AppConfig被声明在com.acme包中(或任何com.acme子包)，它会在调用scan()期间被选出来。在refresh()后，其所有@Bean方法都将被处理并注册为容器内的Bean定义。

通过AnnotationConfigWebApplicationContext支持Web应用程序

AnnotationConfigWebApplicationContext提供了AnnotationConfigApplicationContext的WebApplicationContext变体。当配置Spring的ContextLoaderListener servlet监听器、Spring MVC DispatcherServlet 等等的时候，你可以使用这个实现，下面的web.xml片段配置一个典型的Spring MVC web应用程序(注意：contextClass使用context-param和init-param)：

<web-app>
    <!--
配置ContextLoaderListener使用AnnotationConfigWebApplicationContext替换默认的XmlWebApplicationContext-->
    <context-param>
        <param-name>contextClass</param-name>
        <param-value>
            org.springframework.web.context.support.AnnotationConfigWebApplicationContext
        </param-value>
    </context-param>

    <!-- 配置路径必须包含一个或多个以逗号或空格分隔的完全限定的@Configuration类。也可以指定全限定包以进行组件扫描 -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>com.acme.AppConfig</param-value>
    </context-param>

    <!-- 使用ContextLoaderListener引导根应用程序上下文 -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

    <!-- 声明Spring MVC DispatcherServlet -->
    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <!-- 配置 DispatcherServlet 使用AnnotationConfigWebApplicationContext
            替换默认的XmlWebApplicationContext -->
        <init-param>
            <param-name>contextClass</param-name>
            <param-value>
                org.springframework.web.context.support.AnnotationConfigWebApplicationContext
            </param-value>
        </init-param>
        <!--同样，配置路径必须包含一个或多个逗号或空格分隔且完全限定符的@Configuration类 -->
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>com.acme.web.MvcConfig</param-value>
        </init-param>
    </servlet>

    <!-- 为所有/app/*请求映射到dispatcher servlet -->
    <servlet-mapping>
        <servlet-name>dispatcher</servlet-name>
        <url-pattern>/app/*</url-pattern>
    </servlet-mapping>
</web-app>

1.12.3 使用@Bean注解

@Bean是一个方法级别注解并且是XML 元素的直接类比物。这个注解支持一些通过提供的属性，例如： init-method 、destroy-method 、 autowiring

你可以在@Configuration和@Component注解的类上使用@Bean注解。

声明Bean

去声明一个bean，你可以为一个方法注解@Bean。你使用这个方法在ApplicationContext中去注册一个方法返回值指定类型的bean定义。默认情况，bean名称是相同方法名称。下面的例子显示一个@Bean方法声明：

@Configuration
public class AppConfig {

    @Bean
    public TransferServiceImpl transferService() {
        return new TransferServiceImpl();
    }
}

前面的配置与下面的Spring XML完全等效：

<beans>
    <bean id="transferService" class="com.acme.TransferServiceImpl"/>
</beans>

这两者声明都使一个名为transferService的bean在ApplicationContext中可用，并绑定一个TransferServiceImpl类型的对象实例，类似下面文本图片显示：

transferService -> com.acme.TransferServiceImpl

你也可以声明你的@Bean方法为一个接口(或者基类)返回类型，类似下面例子展示：

@Configuration
public class AppConfig {

    @Bean
    public TransferService transferService() {
        return new TransferServiceImpl();
    }
}

但是，这将高级类型预测的可见性限制为指定的接口类型（TransferService）。然而，全类型(TransferServiceImpl)在容器只有一个，受影响的单例bean被初始化。非懒加载单例bean根据它们的声明顺序获取已经初始化实例，当其他组件尝试通过非声明类型去匹配时，你可能看到不同类型匹配结果依赖(例如，@Autowired TransferServiceImpl，仅在实例化transferService bean之后才解析)。

如果你始终通过声明的服务接口引用你的类型，那么你的@Bean返回类型可以安全地加入该设计决策。但是，对于实现多个接口的组件或由其实现类型潜在引用的组件，声明最具体的返回类型（至少与引用你的bean的注入点所要求的具体类型一样）更为安全。备注：意思是如果通过实现类型引用组件时，在定义@Bean方法时返回类型要是具体的实现类型。

Bean依赖

一个被@Bean注解的方法可以有任意个参数，这些参数描述了需要的依赖去构建bean。例如，如果我们的TransferService需要一个AccountRepository，我们可以通过方法参数来实现这种依赖关系，类似下面例子：

@Configuration
public class AppConfig {

    @Bean
    public TransferService transferService(AccountRepository accountRepository) {
        return new TransferServiceImpl(accountRepository);
    }
}

解析机制与基于构造函数的依赖注入几乎相同。查看更详细相关部分。

接受生命周期回调

任何被声明@Bean注解的类支持普通的生命周期回调并且可以使用 JSR-250的@PostConstruct和@PreDestroy注解。查看JSR-250注解更多的详情。

常规的Spring生命周期回调是被完全的支持。如果bean实现InitializingBean、DisposableBean或Lifecycle，它们各自的方法被容器回调。

标准的set*Aware 接口(例如，BeanFactoryAware,、BeanNameAware、MessageSourceAware,、ApplicationContextAware等等)也是完全的被支持。

@Bean注解支持任意的初始化和销毁回调方法，非常类似Spring 中XML元素的init-method和destroy-method属性，类似下面例子显示：

public class BeanOne {

    public void init() {
        // initialization logic
    }
}

public class BeanTwo {

    public void cleanup() {
        // destruction logic
    }
}

@Configuration
public class AppConfig {

    @Bean(initMethod = "init")
    public BeanOne beanOne() {
        return new BeanOne();
    }

    @Bean(destroyMethod = "cleanup")
    public BeanTwo beanTwo() {
        return new BeanTwo();
    }
}

默认情况下，这些bean通过Java配置定义它们有公共的close或shutdown方法自定地加入到销毁回调中。如果你有一个公共的close或shutdown方法并且当容器被关闭时不想被回调，你应该增加@Bean(destroyMethod="")到你的bean定义中去禁止默认的(inferred)模式。

默认情况下，你可能要对通过JNDI获取的资源执行此操作，因为其生命周期在应用程序外部进行管理的。特别是，要确保始终为数据源执行此操作，因为在Java EE应用服务器上这是有问题的。

下面的例子展示怎样去阻止DataSource自动销毁回调。

@Bean(destroyMethod="")
public DataSource dataSource() throws NamingException {
    return (DataSource) jndiTemplate.lookup("MyDS");
}

另外，对于@Bean方法，通常使用编程式地JNDI查找，方法是使用Spring的JndiTemplate或JndiLocatorDelegate帮助器，或者直接使用JNDI InitialContext用法，而不使用JndiObjectFactoryBean变体（这将迫使你将返回类型声明为FactoryBean类型，而不是实际的类型。目标类型，因此很难在打算引用此处提供的资源的其他@Bean方法中用于交叉引用调用。

对于前面示例中的BeanOne，它等效于在构造期间直接调用init()方法，类似下面例子：

@Configuration
public class AppConfig {

    @Bean
    public BeanOne beanOne() {
        BeanOne beanOne = new BeanOne();
        beanOne.init();
        return beanOne;
    }

    // ...
}

当你直接地工作在Java中，你可以对你的对象做任何事而不需要依赖容器生命周期。

指定Bean作用域

Spring包括@Scope注解，因此你可以使用bean的作用域。

使用@Scope注解

你可以指定你的bean定义通过@Bean注解同时也可以指定一个作用域。你可以使用在Bean作用域部分中任何标准的作用域指定。

默认作用域是singleton，但是你可以覆盖这个通过@Scope注解，类似下面例子显示：

@Configuration
public class MyConfiguration {

    @Bean
    @Scope("prototype")
    public Encryptor encryptor() {
        // ...
    }
}

@Scope和scoped-proxy

Spring提供通过作用域代理处理作用域依赖的便捷方式。当使用XML配置< aop:scoped-proxy/>是最简单创建一个代理方式。使用@Scope注解在Java中配置bean，可以通过proxyMode属性提供同等的支持。默认是没有代理(ScopedProxyMode.NO)，但是你可以指定ScopedProxyMode.TARGET_CLASS或ScopedProxyMode.INTERFACES

如果你使用Java，将XML参考文档中的作用域代理示例(请参阅作用域代理)移植到我们的@Bean，它类似于以下内容：

// Http session作用域bean 暴露为代理
@Bean
@SessionScope
public UserPreferences userPreferences() {
    return new UserPreferences();
}

@Bean
public Service userService() {
    UserService service = new SimpleUserService();
    // 引用UserPreferences
    service.setUserPreferences(userPreferences());
    return service;
}

自定义Bean名称

默认情况下，配置类使用@Bean方法的名称作为bean名称。这个功能可以被覆盖，通过@Bean的name属性，类似下面例子：

@Configuration
public class AppConfig {

   @Bean(name = "myThing")
   public Thing thing() {
       return new Thing();
   }
}

Bean别名

类似在bean的命名中讨论，有时候给一个简单bean多个名称，也称为Bean别名。@Bean注解的name属性接受一个字符串数组为这个别名。下面例子展示怎样去设置bean的别名：

@Configuration
public class AppConfig {

    @Bean({"dataSource", "subsystemA-dataSource", "subsystemB-dataSource"})
    public DataSource dataSource() {
        // instantiate, configure and return DataSource bean...
    }
}

@Bean描述

有时候，有助于提供有关bean的更详细的文本描述。当这些bean被暴露为监控目的时，是非常有用的。

去增加一个描述到@Bean，你可以使用 @Description 注解，类似下面例子展示：

@Configuration
public class AppConfig {

    @Bean
    @Description("Provides a basic example of a bean")
    public Thing thing() {
        return new Thing();
    }
}

1.12.4 使用`@Configuration`注解

@Configuration是一个类级别注解，它表示对象是bean定义的源。@Configuration类声明bean通过公共@Bean注解方法。在@Configuration类上调用@Bean方法能被使用去定义Bean之间依赖关系。查看基础概念：@Bean和@Configuration

bean间注入的依赖关系

当Bean彼此依赖时，表达这种依赖就像让一个bean方法调用另一个一样简单，类似下面例子展示：

@Configuration
public class AppConfig {

    @Bean
    public BeanOne beanOne() {
        return new BeanOne(beanTwo());
    }

    @Bean
    public BeanTwo beanTwo() {
        return new BeanTwo();
    }
}

在前面的例子中，beanOne通过构造函数注入引用beanTwo。

仅仅当@Bean方法被声明在@Configuration类中时，这方法声明bean间的依赖关系有效。你不能通过使用普通的@Component声明bean间的依赖关系。

查找方法注入

如前所述，查找方法注入是一个高级特性，它很少地使用。在一些单例作用域bean依赖原型作用域bean场景，它是非常有用的。使用Java为配置类型实现这个模式提供一种自然方法。下面例子展示怎样去查找方法注入：

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

    // okay... but where is the implementation of this method?
    protected abstract Command createCommand();
}

通过使用Java配置，在该子类中，你可以创建一个CommandManager子类，抽象的createCommand()方法将被覆盖，以使其查找新的（原型）command对象。通过使用Java配置。下面例子展示怎样去做：

@Bean
@Scope("prototype")
public AsyncCommand asyncCommand() {
    AsyncCommand command = new AsyncCommand();
    // inject dependencies here as required
    return command;
}

@Bean
public CommandManager commandManager() {
    // return new anonymous implementation of CommandManager with createCommand()
    // overridden to return a new prototype Command object
    return new CommandManager() {
        protected Command createCommand() {
            return asyncCommand();
        }
    }
}

有关基于Java的配置在内部如何工作的更多信息

考虑下面例子，它展示了一个@Bean注解的方法被调用两次。

@Configuration
public class AppConfig {

    @Bean
    public ClientService clientService1() {
        ClientServiceImpl clientService = new ClientServiceImpl();
        clientService.setClientDao(clientDao());
        return clientService;
    }

    @Bean
    public ClientService clientService2() {
        ClientServiceImpl clientService = new ClientServiceImpl();
        clientService.setClientDao(clientDao());
        return clientService;
    }

    @Bean
    public ClientDao clientDao() {
        return new ClientDaoImpl();
    }
}

clientDao()在clientService1()被调用一次并且在clientService2()也调用一次。因为这个方法创建一个新的ClientDaoImpl实例并且返回它，你通常希望有两个实例(每个服务一个)。那肯定是有问题的：在Spring中，默认情况实例化bean作用域是singleton。这就是神奇之处：所有@Configuration类在运行时是CGLIB的子类。在子类中，在调用父方法创建实例之前，子类方法首先检查容器缓存bean。

这种行为根据你的bean作用域可能不同。我们在这里讨论的单例bean。

在Spring3.2以后，不在需要添加CGLIB到你的类路径下，因为CGLIB类已经被重新打包在org.springframework.cglib下并且直接地包含在spring-core jar中。

由于CGLIB在启动时会动态添加功能，因此存在一些限制。特别地，配置类不能是final。然而，在Spring4.3以后，任何构造函数在配置类上是被允许的，包括@Autowired或没有默认参数的构造函数申明默认注入的使用。

如果你想避免CGLIB的限制，考虑在你非@Configuration类(例如，一个普通的@Component替换)上声明你的@Bean方法。在@Bean方法之间跨方法调用不会被拦截，因此你必在须构造函数或方法级别只依赖需要注入的。

代码示例：com.liyong.ioccontainer.starter.BaseJavaConfigIocContainer

1.12.5 编写基于Java的配置

Spring的基于Java配置特性允许你编写注解，这样可以降低你的配置复杂性。

使用@Import注解

类似元素被使用在Spring XML文件中去帮助模块化配置，@Import注解允许去其他配置类中加载@Bean定义，类似下面的例子展示：

@Configuration
public class ConfigA {

    @Bean
    public A a() {
        return new A();
    }
}

@Configuration
@Import(ConfigA.class)
public class ConfigB {

    @Bean
    public B b() {
        return new B();
    }
}

当初始化上下文时，不需要去指定ConfigA.class和ConfigB.class，仅仅需要去显示地提供ConfigB，类似下面例子展示：

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(ConfigB.class);

    // now both beans A and B will be available...
    A a = ctx.getBean(A.class);
    B b = ctx.getBean(B.class);
}

这个方式简化容器的实例化，仅仅一个类需要去处理，而不是在构造期间潜在地记住大量的@Configuration类。

在Spring4.2以后，@Import也支持引用常规的组件类，类似AnnotationConfigApplicationContext.register方法。如果你想避免组件扫描，这是非常有用地，通过使用一些配置类作为入口点显示定义所有组件。

在被导入的@Bean定义中注入依赖

前面的示例有效，但过于简单。在大多数时间场景中，Bean在配置类之间相互依赖。当使用XML时，这不是问题，因为不涉及编译器并且你可以声明 ref="someBean" 并信任Spring在容器初始化期间进行处理。当使用@Configuration类时，Java编译器在配置模型上约束，因为对其他bean引用必须是有效的Java语法。

幸好地，解决这个问题是非常简单的。像我们以前讨论过的，@Bean方法可以有任意数量的参数，这些参数描述了bean的依赖。考虑下面更真实的场景对于这些@Configuration类，每一个bean在其他类中被定义：

@Configuration
public class ServiceConfig {

    @Bean
    public TransferService transferService(AccountRepository accountRepository) {
        return new TransferServiceImpl(accountRepository);
    }
}

@Configuration
public class RepositoryConfig {

    @Bean
    public AccountRepository accountRepository(DataSource dataSource) {
        return new JdbcAccountRepository(dataSource);
    }
}

@Configuration
@Import({ServiceConfig.class, RepositoryConfig.class})
public class SystemTestConfig {

    @Bean
    public DataSource dataSource() {
        // return new DataSource
    }
}

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
    // everything wires up across configuration classes...
    TransferService transferService = ctx.getBean(TransferService.class);
    transferService.transfer(100.00, "A123", "C456");
}

这里有其他的方式去实现相同的结果。记住@Configuration类最终只是容器中的另一个bean：这意味着它们可以利用@Autowired和@Value注入以及其他与其他bean相同的特性。

确保以这种方式注入的依赖项只是最简单的一种。@Configuration类是在上下文初始化期间非常早地处理的，并且强制以这种方式注入依赖项可能导致意外的早期初始化。如上例所示，尽可能使用基于参数的注入。

另外，通过@Bean定义BeanPostProcessor和BeanFactoryPostProcessor时要特别小心。这些应该通常地被声明为static @Bean方法，不要触发它们包含的配置类初始化。除此之外，@Autowired和@Value可能在配置类上不能工作，因为它作为bean实例被创建早于 AutowiredAnnotationBeanPostProcessor。

下面例子展示一个bean怎样被装配到其他bean：

@Configuration
public class ServiceConfig {

    @Autowired
    private AccountRepository accountRepository;

    @Bean
    public TransferService transferService() {
        return new TransferServiceImpl(accountRepository);
    }
}

@Configuration
public class RepositoryConfig {

    private final DataSource dataSource;

    public RepositoryConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Bean
    public AccountRepository accountRepository() {
        return new JdbcAccountRepository(dataSource);
    }
}

@Configuration
@Import({ServiceConfig.class, RepositoryConfig.class})
public class SystemTestConfig {

    @Bean
    public DataSource dataSource() {
        // return new DataSource
    }
}

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
    // everything wires up across configuration classes...
    TransferService transferService = ctx.getBean(TransferService.class);
    transferService.transfer(100.00, "A123", "C456");
}

在@Configuration类中构造方法注入仅支持在Spring4.3以后。注意：如果目标bean定义仅有一个构造函数，那么不需要去指定@Autowired。

代码示例：com.liyong.ioccontainer.starter.BeanAndConfigurationImportContainer

全限定导入bean以更容易导航

在前面的场景中，使用@Autowired工作很好并且提供期望的模块化，但是确定自动装配 bean的定义是在哪里声明的仍然有些模棱两可。例如，作为一个开发者看到ServiceConfig，怎样确切的知道@Autowired AccountRepository bean在哪里定义的？它在代码中不是明确的，这可能很好。记住， Spring Tools 为Eclipse提供可以渲染图形的工具，这些图形显示了所有的对象是怎样连接的，这可能是你需要的。你的Java IDE能更容易地找到所有声明和使用AccountRepository类型并且快速地显示@Bean方法的路径以及返回类型。

如果这种歧义是不可接受的，并且你希望从IDE内部直接从一个@Configuration类导航到另一个@Configuration类，请考虑自动装配配置类本身。下面例子显示怎样去做：

@Configuration
public class ServiceConfig {

    @Autowired
    private RepositoryConfig repositoryConfig;

    @Bean
    public TransferService transferService() {
        // navigate 'through' the config class to the @Bean method!
        return new TransferServiceImpl(repositoryConfig.accountRepository());
    }
}

在前面情况中，AccountRepository完整的显示定义。但是，ServiceConfig现在紧紧的耦合到RepositoryConfig。这就是需要权衡的。通过使用基于接口或基于抽象类的@Configuration类，可以在某种程度上缓解这种紧密耦合。考虑下面例子：

@Configuration
public class ServiceConfig {

    @Autowired
    private RepositoryConfig repositoryConfig;

    @Bean
    public TransferService transferService() {
        return new TransferServiceImpl(repositoryConfig.accountRepository());
    }
}

@Configuration
public interface RepositoryConfig {

    @Bean
    AccountRepository accountRepository();
}

@Configuration
public class DefaultRepositoryConfig implements RepositoryConfig {

    @Bean
    public AccountRepository accountRepository() {
        return new JdbcAccountRepository(...);
    }
}

@Configuration
@Import({ServiceConfig.class, DefaultRepositoryConfig.class})  // import the concrete config!
public class SystemTestConfig {

    @Bean
    public DataSource dataSource() {
        // return DataSource
    }

}

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(SystemTestConfig.class);
    TransferService transferService = ctx.getBean(TransferService.class);
    transferService.transfer(100.00, "A123", "C456");
}

现在，ServiceConfig与具体的DefaultRepositoryConfig松散耦合，并且内建IDE工具仍然非常有用：你可以容易地获取RepositoryConfig实现的层级。通过这种方式，导航@Configuration类及其依赖项与导航基于接口的代码的通常过程没有什么不同。

如果你想流畅启动创建这些bean的顺序，考虑声明它们为@Lazy(用于首次访问而不是启动时创建)或像@DependsOn其他bean(确保其他指定bean在当前bean被创建之前，而不受后者直接依赖关系的影响)。

条件地包含@Configuration类或@Bean方法

根据某些系统状态，有条件地启用或禁用完整的@Configuration类甚至单个@Bean方法，通常很有用。说明：可以启用/禁止@Configuration类或者@Configuration类中的@Bean方法。一个常用的例子是去使用@Profile注解去激活bean，仅仅当在Spring中的Environment指定的profile被激活时(查看Bean定义 Profiles 详情)。

@Profile注解通过使用一个非常灵活的注解叫做 @Conditional实现的。@Conditional注解指示在注册@Bean之前应咨询特定org.springframework.context.annotation.Condition实现。

Condition接口的实现接口提供一个matches(…)方法，它会返回true或false。例如，下面的清单显示Condition对@Profile真实实现：

@Override
public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
    // Read the @Profile annotation attributes
    MultiValueMap<String, Object> attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());
    if (attrs != null) {
        for (Object value : attrs.get("value")) {
            if (context.getEnvironment().acceptsProfiles(((String[]) value))) {
                return true;
            }
        }
        return false;
    }
    return true;
}

查看 @Conditional文档更多详细。

结合Java和XML配置

Spring的@Configuration类不能100%的完成替换Spring XML。一些工具(如Spring XML namespaces)仍然是配置容器的理想方法。在使用XML方便或有必要的情况下，你可以选择：使用“ClassPathXmlApplicationContext以“ XML中心”方式实例化容器，或通过使用AnnotationConfigApplicationContext和“ Java配置中心”方式实例化容器。 @ImportResource注解可根据需要导入XML。

以XML为中心的@Configuration类的使用

从XML引导Spring容器并以特别的方式包含@Configuration类可能更好。例如，在使用Spring XML的大型现有代码库中，根据需要创建@Configuration类并且现有XML文件中将它们包含在内变得更加容易。在本节的后面，我们将介绍在这种“以XML为中心”的情况下使用@Configuration类的选项。

声明@Configuration类似普通的Spring元素

记住@Configuration类最终在容器中是bean定义。在这一系列例子中，我们创建@Configuration类命名为AppConfig并且包含它在system-test-config.xml中类似定义。因为<context:annotation-config/>已经打开，容器在AppConfig中识别@Configuration注解和处理@Bean方法声明。

下面例子显示在Java中普通的配置：

@Configuration
public class AppConfig {

    @Autowired
    private DataSource dataSource;

    @Bean
    public AccountRepository accountRepository() {
        return new JdbcAccountRepository(dataSource);
    }

    @Bean
    public TransferService transferService() {
        return new TransferService(accountRepository());
    }
}

下面例子显示system-test-config.xml文件一部分:

<beans>
    <!-- enable processing of annotations such as @Autowired and @Configuration -->
    <context:annotation-config/>
    <context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>

    <bean class="com.acme.AppConfig"/>

    <bean class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="url" value="${jdbc.url}"/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
    </bean>
</beans>

下面例子显示可能的jdbc.properties文件：

jdbc.url=jdbc:hsqldb:hsql://localhost/xdb
jdbc.username=sa
jdbc.password=

public static void main(String[] args) {
    ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/com/acme/system-test-config.xml");
    TransferService transferService = ctx.getBean(TransferService.class);
    // ...
}

在system-test-config.xml文件中，AppConfig 没有声明id元素。虽然这样做是可以接受的，但这是不必要的，因为没有其他bean引用它，而且不太可能通过名称显式地从容器中获取它。同样，DataSource bean只能按类型自动装配，因此也不严格要求显式bean id。

使用 **<context:component-scan/>**选择@Configuration类

因为@Configuration元注解是@Component，被@Configuration注解的类是组件自动地扫描的候选者。使用相同的场景在前面例子已经描述，我们可以重定义system-test-config.xml去利用组件扫描。注意，在这个场景中，我们不需要显示的声明<context:annotation-config/>，因为<context:component-scan/>激活相同的功能。

下面例子显示修改后的system-test-config.xml文件：

<beans>
    <!-- picks up and registers AppConfig as a bean definition -->
    <context:component-scan base-package="com.acme"/>
    <context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>

    <bean class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="url" value="${jdbc.url}"/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
    </bean>
</beans>

@Configuration以类为中心的XML与@ImportResource的结合使用

在应用中，@Configuration类是配置容器的主要机制，但是仍然可能需要至少使用一些XML。在这个场景中，你可以使用@ImportResource和定义你需要的XML。这样做实现了“以Java为中心”的方法来配置容器，并使XML保持在最低限度。下面例子展示了怎样去使用@ImportResource注解去实现“以Java为中心”配置并在需要的时候使用XML：

@Configuration
@ImportResource("classpath:/com/acme/properties-config.xml")
public class AppConfig {

    @Value("${jdbc.url}")
    private String url;

    @Value("${jdbc.username}")
    private String username;

    @Value("${jdbc.password}")
    private String password;

    @Bean
    public DataSource dataSource() {
        return new DriverManagerDataSource(url, username, password);
    }
}

properties-config.xml：

<beans>
    <context:property-placeholder location="classpath:/com/acme/jdbc.properties"/>
</beans>

jdbc.properties：

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
    TransferService transferService = ctx.getBean(TransferService.class);
    // ...
}

代码示例：com.liyong.ioccontainer.starter.BaseJavaConfigAndXmlIocContainer

作者

个人从事金融行业，就职过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就职于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。

博客地址： http://youngitman.tech

Spring 5 中文解析核心篇-IoC容器之基于Java容器配置原创