skip to content

What are Spring stereotype annotations, and what is the relationship between @Component and @Service / @Repository / @Controller?

level: juniorimportance: must knowfreq 80%

answer

  1. @Component = base marker
  2. @Service/@Repository/@Controller meta-annotated with @Component
  3. component scanning registers beans
  4. @Repository adds exception translation
  5. @Controller needed for MVC routing

basics

~10 s

Stereotype annotations mark a class as a Spring-managed bean so component scanning picks it up. @Component is the base; @Service, @Repository, and @Controller are specializations of @Component for the service, persistence, and web layers.

solid answer

~40 s

Stereotype annotations tell Spring's classpath component scanning to detect a class and register it as a bean in the ApplicationContext. @Component is the generic marker. @Service, @Repository, and @Controller are meta-annotated with @Component, so they behave the same way for registration but add semantic intent for a layer: @Service for business logic, @Repository for persistence, @Controller for web MVC handlers. @Repository additionally enables persistence-exception translation, and @Controller (plus @RestController) is recognized by Spring MVC for request mapping. Using the specific stereotype documents the class's role and lets tooling and other Spring features (like AOP pointcuts on @Service) target layers. Component scanning is enabled via @ComponentScan or Spring Boot's @SpringBootApplication.

code

java · 16 lines
java
import org.springframework.stereotype.Service;
import org.springframework.stereotype.Repository;

@Service // business layer bean, name -> "orderService"
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) { this.repo = repo; }
}

@Repository // persistence bean + exception translation
public class OrderRepository {
    // JDBC/JPA access here
}

// Scanning is on via @SpringBootApplication in the app's root package,
// or explicitly: @ComponentScan(basePackages = "com.example.app")

go deeper

for a junior

Know the four names, that @Component is the base, and that scanning turns them into beans.

for a middle

Explain meta-annotation relationship, default bean naming, and that @Repository/@Controller add layer behavior.

for a senior

Discuss when the specialization matters (exception translation, MVC detection, AOP pointcuts) vs. pure documentation.

for a principal

Frame stereotype choice as an architecture/convention decision and note the scanning/filter mechanics and extensibility.

A **stereotype annotation** is a marker that classifies a class by its role in the application and, crucially, makes it a candidate for **classpath component scanning**. When Spring scans packages (triggered by `@ComponentScan`, or implicitly by `@SpringBootApplication`), it looks for classes annotated with `@Component` or any annotation that is itself meta-annotated with `@Component`, and registers each as a **bean definition** in the `ApplicationContext`. **`@Component`** (`org.springframework.stereotype.Component`) is the base, generic stereotype: 'this is a Spring-managed component.' **Specializations**, all meta-annotated with `@Component`: - **`@Service`** (`org.springframework.stereotype.Service`) — marks a business/service-layer class. Functionally identical to `@Component` for registration; the value is semantic clarity and being a target for layer-specific AOP or conventions. - **`@Repository`** (`org.springframework.stereotype.Repository`) — marks a persistence/DAO class. Beyond registration, it is a marker for **automatic persistence exception translation** (see below). - **`@Controller`** (`org.springframework.stereotype.Controller`) — marks a Spring MVC web controller; Spring MVC's `RequestMappingHandlerMapping` detects these to route HTTP requests to `@RequestMapping`/`@GetMapping` handler methods. `@RestController` is `@Controller` + `@ResponseBody`. **Why not just use @Component everywhere?** For bean registration alone, the four are interchangeable. But the specializations: (1) document architectural intent; (2) let you write pointcuts / conventions targeting a layer; (3) unlock layer features — `@Repository` triggers exception translation, `@Controller` is required for MVC request handling (a plain `@Component` will not be treated as a web controller). Future Spring versions may attach more behavior to a specific stereotype, so choosing the right one is future-proofing. **How registration works:** the scanner uses a `ClassPathScanningCandidateComponentProvider` with an `AnnotationTypeFilter` for `@Component`. Because the specializations carry `@Component` transitively (meta-annotation), they all match. Each detected class gets a default bean name from `AnnotationBeanNameGenerator` — the uncapitalized simple class name (e.g., `UserService` → `userService`) — unless you supply a value like `@Service("myBean")`. **Common gotchas:** - The class must live under a scanned base package. Boot scans the package of the `@SpringBootApplication` class and below by default. - Stereotypes create **singleton** beans by default; add `@Scope("prototype")` etc. to change. - `@Configuration` is also a specialization of `@Component`, but it is used for `@Bean` factory methods, not as a plain component. - Interfaces and abstract classes annotated with a stereotype are not instantiated as beans; annotate the concrete class.

  • If @Service and @Component are functionally the same for registration, why prefer @Service?
    It documents the layer/role, allows layer-targeted AOP pointcuts and conventions, and future-proofs against Spring attaching layer-specific behavior to the specialization.
  • What default bean name does @Service on class UserService produce?
    "userService" — AnnotationBeanNameGenerator uncapitalizes the simple class name unless you pass an explicit value.

saying these in an interview costs you the question

  • Saying the specializations do completely different registration than @Component
  • Claiming a plain @Component works as an MVC controller
  • Thinking stereotypes must be on interfaces
  • Believing stereotype beans are prototype-scoped by default

context

resolving links…