Detailed explanation
In Spring, @Component, @Service, @Repository, and @Controller are stereotype annotations that identify classes intended to be managed by the Spring container. With component scanning enabled for their packages, Spring detects these classes and registers bean definitions. It then creates and wires their instances according to the configured scope and lifecycle. The main difference is the architectural role each annotation communicates, plus specific framework behaviour associated with repositories and controllers. An annotation alone does not guarantee discovery: the class must be within the scan configuration or registered another way.
@Component is the general-purpose stereotype for classes that do not fit a more specific layer, such as a helper or adapter. @Service, @Repository, and @Controller are themselves meta-annotated with @Component, so component scanning recognises them too. @Service identifies business-layer logic, such as validating an order and coordinating repository calls. It does not automatically enable transactions or add special processing compared with @Component; transaction boundaries normally require @Transactional and transaction-management configuration. Its value is expressing intent and supporting conventions or annotation-based pointcuts.
@Repository identifies a persistence-layer component, such as a DAO that uses JPA or JDBC. Beyond documenting its purpose, it makes the component eligible for Spring's persistence exception translation. When the required infrastructure is configured, typically through PersistenceExceptionTranslationPostProcessor, supported persistence-provider exceptions can be translated into Spring's unchecked DataAccessException hierarchy. This gives application code a more consistent exception model across persistence technologies. Do not claim that @Repository translates every exception, or that merely placing it on any class guarantees translation without the necessary infrastructure.
@Controller identifies a Spring MVC web controller. With MVC infrastructure configured, request-handling methods are usually mapped using @RequestMapping, @GetMapping, or similar annotations. A String return value typically represents a view name unless response-body handling is requested. The example uses @RestController, which combines @Controller and @ResponseBody: return values are written to the HTTP response through message converters, often as JSON. In interviews, distinguish shared bean discovery from layer-specific meaning and behaviour, and explain the usual request flow: controller to service to repository.
Key points to remember
- @Component is the generic stereotype for a Spring-managed component discovered through component scanning.
- @Service marks business logic but does not automatically make methods transactional.
- @Repository marks persistence components and enables eligibility for configured persistence exception translation.
- @Controller marks Spring MVC controllers whose methods handle mapped web requests.
- @RestController combines @Controller and @ResponseBody for response-body handling rather than view-name resolution.
Common mistakes candidates make
- Assuming stereotype annotations register classes even when their packages are not scanned.
- Claiming @Service automatically enables transactions or @Repository translates exceptions without supporting infrastructure.
- Treating @Controller and @RestController as identical, especially when explaining String return values.
Likely follow-up questions
Can I replace @Service or @Repository with @Component?
For basic bean discovery and dependency injection, usually yes, provided component scanning includes the class. However, you lose the clearer architectural meaning, and replacing @Repository can remove eligibility for annotation-based persistence exception translation.
What does @Controller return compared with @RestController?
A @Controller method returning a String typically supplies a view name, unless it uses @ResponseBody or another response-oriented mechanism. With @RestController, response-body handling applies by default; objects may become JSON, while Strings are generally written as text, depending on the selected message converter.
Does @Repository create Spring Data repository implementations?
No, the stereotype annotation itself does not generate repository implementations. Spring Data uses separate repository infrastructure to create proxies for eligible repository interfaces, which generally do not need an explicit @Repository annotation.
Interview tip: Start with their shared component-scanning behaviour, explain each layer's role, and finish with exception translation and @RestController as the important behavioural distinctions.