Till now so many asked about the differences
and similarities among stereotypes in spring. Let’s look at the similarity
first.
With respect to scan-auto-detection and dependency injection for
BeanDefinition all
these annotations (viz., @Component, @Service, @Repository, @Controller) are
the same. We can use one in place of another and can
still get our way around.
Differences between @Component, @Repository, @Controller and
@Service
@Component
This is a general-purpose stereotype annotation indicating that
the class is a spring component.
Why @Component
<context:component-scan> only scans @Component and does not look for @Controller, @Service and @Repository in general. They are scanned because
they themselves are annotated with @Component.
Just take a look at @Controller, @Service and @Repository annotation definitions:
@Component
public
@interface Service {
….
}
@Component
public
@interface Repository {
….
}
@Component
public
@interface Controller {
…
}
Thus, it’s not wrong to say that @Controller, @Service and @Repository are special types of @Component annotation. <context:component-scan> picks them up and registers their
following classes as beans, just as if they were annotated with @Component.
Special type annotations are also scanned, because they
themselves are annotated with @Component annotation, which means they are
also @Components. If we define our
own custom annotation and annotate it with @Component, it will also get scanned with <context:component-scan>
@Repository
This is to indicate that the class defines a data repository.
Why @Repository?
In addition to pointing out, that this is an Annotation based Configuration, @Repository’s job is to catch platform specific
exceptions and re-throw them as one of Spring’s unified unchecked exception.
For this, we’re provided with PersistenceExceptionTranslationPostProcessor, that we are required to add in our Spring’s
application context like this:
<bean
class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
This bean post processor adds an advisor to any bean that’s
annotated with @Repository so that any
platform-specific exceptions are caught and then re-thrown as one of Spring’s
unchecked data access exceptions.
@Controller
The @Controller annotation
indicates that a particular class serves the role of a controller.
Why @Controller?
We cannot switch this annotation with any other like @Service or @Repository, even though they look same. The dispatcher
scans the classes annotated with @Controller and detects methods annotated with @RequestMapping annotations within them. We can
use @RequestMapping on/in
only those methods whose classes are annotated with @Controller and it will NOT work with @Component, @Service, @Repository etc...
@Service
@Service beans hold the business logic and call
methods in the repository layer.
Why @Service?
Apart from the fact that it's used to indicate, that it's
holding the business logic, there’s nothing else noticeable in this annotation
for now.
