我知道在spring 2.5中引入@Component注释是为了通过使用类路径扫描来摆脱xml bean定义。

@Bean是在spring 3.0中引入的,可以和@Configuration一起使用,以便完全摆脱xml文件,而使用java配置。

是否有可能重用@Component注释而不是引入@Bean注释?我的理解是,最终目标是在这两种情况下都创建bean。


当前回答

以上答案的附加分数

假设我们有一个在多个应用程序中共享的模块,它包含一些服务。并不是每个应用程序都需要。

如果在这些服务类上使用@Component并且在应用程序中扫描组件,

我们最终可能会检测到比必要的更多的bean

在这种情况下,您要么必须调整组件扫描的过滤,要么提供即使是未使用的bean也可以运行的配置。否则,应用程序上下文将无法启动。

在这种情况下,最好使用@Bean注释并只实例化那些bean,

每个应用程序都需要哪些

因此,本质上,使用@Bean向上下文添加第三方类。@Component如果它只是在你的单个应用程序中。

其他回答

@Component和@Bean做两件完全不同的事情,不应该混淆。

@Component(以及@Service和@Repository)用于使用类路径扫描自动检测和自动配置bean。在带注释的类和bean之间存在隐式的一对一映射(即每个类一个bean)。这种方法对连接的控制非常有限,因为它是纯声明性的。

@Bean用于显式地声明单个bean,而不是像上面那样让Spring自动执行。它将bean的声明与类定义解耦,并允许您按照自己的选择创建和配置bean。

回答你的问题…

是否有可能重用@Component注释而不是引入@Bean注释?

当然,可能;但他们选择不这样做,因为这两者是完全不同的。春天已经够让人迷惑了,不要再把水弄脏了。

假设我想要特定的实现依赖于某种动态状态。 @Bean非常适合这种情况。

@Bean
@Scope("prototype")
public SomeService someService() {
    switch (state) {
    case 1:
        return new Impl1();
    case 2:
        return new Impl2();
    case 3:
        return new Impl3();
    default:
        return new Impl();
    }
}

然而,@Component没有办法做到这一点。

@ component 适用于元件扫描和自动布线。

什么时候应该使用@Bean?

有时自动配置不是一个选项。什么时候?让我们想象一下,您想要连接来自第三方库的组件(您没有源代码,所以不能用@Component注释它的类),因此自动配置是不可能的。

@Bean注释返回一个对象,spring应该在应用程序上下文中将该对象注册为bean。方法主体承担负责创建实例的逻辑。

1. 关于@ component @Component的功能类似于@Configuration。 它们都表明带注释的类有一个或多个需要注册到Spring-IOC-Container的bean。 由@Component注释的类,我们称之为Spring的Component。它是一个包含多个bean的概念。 Spring需要自动扫描组件类来注册组件类的那些bean。

2. 关于@ bean @Bean用于注释组件类的方法(如上所述)。它表示由带注释的方法返回的实例需要注册到Spring-IOC-Container。

3.结论 两者的区别是比较明显的,它们在不同的情况下使用。 一般用法是:

    // @Configuration is implemented by @Component
    @Configuration
    public ComponentClass {

      @Bean
      public FirstBean FirstBeanMethod() {
        return new FirstBean();
      }

      @Bean
      public SecondBean SecondBeanMethod() {
        return new SecondBean();
      }
    }

创建@Bean是为了避免在编译时耦合Spring和业务规则。这意味着您可以在其他框架(如PlayFramework或JEE)中重用业务规则。

此外,在默认的Spring实例化还不够的情况下,您可以完全控制如何创建bean。

我写了一篇关于它的文章。

https://coderstower.com/2019/04/23/factory-methods-decoupling-ioc-container-abstraction/