Modul 0·Spring-Grundlagen

Konfiguration & Component Scanning

Beans mit @Configuration und @Bean deklarieren, Component Scanning mit Stereotypen und wie beide Stile zusammenspielen.

16 Min. LesezeitFortgeschritten

Deutsche Übersetzung in Arbeit

Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.

Auf dieser Seite

The container can only wire beans it knows about. So how do you tell Spring which objects to manage? There are two styles, and real applications use both together.

Style 1: component scanning with stereotypes

Annotate your own classes and let Spring discover them. The annotations are called stereotypes - they mark a class as a bean and hint at its role:

@Component     // generic managed component
@Service       // business logic - a @Component with a clearer intent
@Repository     // data access - also translates DB exceptions
@Controller    // web endpoint (or @RestController for JSON APIs)

They are functionally almost identical - all register a bean - but each documents what kind of component it is:

@Service
class BookService {
    private final BookRepository repository;
    BookService(BookRepository repository) { this.repository = repository; }
}

@Repository
class BookRepository { /* ... */ }

Component scanning finds them. You point Spring at a base package and it scans for stereotype-annotated classes:

@Configuration
@ComponentScan("com.bookvault")   // scan this package and its sub-packages
class AppConfig { }

Spring Boot scans for you

In a Boot app, @SpringBootApplication already includes @ComponentScan for the package of your main class and everything beneath it. Put your code under that package and every stereotype-annotated class is picked up automatically - you rarely write @ComponentScan yourself.

Style 2: @Configuration and @Bean

Component scanning only works on classes you can annotate. But what about a class from a third-party library - a data source, an HTTP client, an object mapper? You can't add @Component to code you don't own.

For those, write a @Bean factory method inside a @Configuration class:

@Configuration
class InfrastructureConfig {

    @Bean
    ObjectMapper objectMapper() {                 // you construct it; Spring manages it
        return JsonMapper.builder()
            .findAndAddModules()
            .build();
    }

    @Bean
    RestClient bookApiClient(ObjectMapper mapper) {   // params are injected beans
        return RestClient.builder()
            .baseUrl("https://api.example.com")
            .build();
    }
}

The method returns the object and its name becomes the bean name. Notice bookApiClient takes ObjectMapper as a parameter - Spring injects the bean defined by the other @Bean method. Configuration classes wire each other.

Stereotypes are staff badges; @Bean is a purchase order

Stereotype annotations are like giving your own employees a staff badge - they walk in and the container recognizes them. But you can't badge an outside contractor's equipment. For third-party objects you write a purchase order (@Bean): "build me one of these, configured like so," and the container stocks it and hands it out like any other bean.

Which one, when?

Use…	For…
Stereotypes + scanning	Your own classes - services, repositories, controllers
`@Configuration` + `@Bean`	Third-party classes, or beans needing custom construction logic

Both produce ordinary beans that inject into each other identically. A typical app is mostly stereotype-annotated classes, with a handful of @Configuration classes for infrastructure.

Which style for each?

For each object, decide whether you'd register it with a stereotype (@Component/@Service/…) or a @Bean method, and why:

Your own InvoiceService class.
A DataSource from the HikariCP connection-pool library.
Your own PdfRenderer class.
A Clock you want fixed to UTC for consistent timestamps.

When must you use a @Bean method instead of a stereotype annotation like @Service?

Key takeaways

Beans are declared two ways: stereotype annotations (@Component/@Service/@Repository/@Controller) found by component scanning, or @Bean methods in a @Configuration class.
Stereotypes differ mainly in documented intent; @Repository also translates data-access exceptions.
Spring Boot's @SpringBootApplication auto-scans the main class's package and below, so scanning is usually automatic.
Use @Bean factory methods for third-party classes you can't annotate, or when construction needs custom logic; @Bean method parameters are injected beans.
Both styles produce ordinary, mutually injectable beans - real apps mix them.

War diese Lektion hilfreich?

Diese Seite auf GitHub bearbeiten