Como muchas de las respuestas ya indican para qué se usan estas anotaciones, aquí nos centraremos en algunas diferencias menores entre ellas.
Primero la similitud
El primer punto que vale la pena resaltar nuevamente es que, con respecto a la detección automática de escaneo y la inyección de dependencia para BeanDefinition, todas estas anotaciones (a saber, @Component, @Service, @Repository, @Controller) son las mismas. Podemos usar uno en lugar de otro y aún así podemos movernos.
Diferencias entre @Component, @Repository, @Controller y @Service
@Componente
Esta es una anotación de estereotipo de propósito general que indica que la clase es un componente de resorte.
Lo que es especial acerca de @Component
<context:component-scan> solo escanea@Componenty no busca@Controller,@Servicey@Repositoryen general. Se escanean porque ellos mismos están anotados con@Component.
Basta con echar un vistazo a @Controller, @Servicey @Repositorylas definiciones de anotación:
@Component
public @interface Service {
….
}
@Component
public @interface Repository {
….
}
@Component
public @interface Controller {
…
}
Por lo tanto, no está mal decir eso @Controller, @Servicey @Repositoryson tipos especiales de @Componentanotación. <context:component-scan>los recoge y registra sus siguientes clases como beans, como si estuvieran anotados con @Component.
Las anotaciones de tipo especial también se escanean, porque ellas mismas están anotadas con @Componentanotaciones, lo que significa que también son @Components. Si definimos nuestra propia anotación personalizada y la anotamos @Component, también se escaneará con<context:component-scan>
@Repositorio
Esto es para indicar que la clase define un repositorio de datos.
¿Qué tiene de especial @Repository?
Además de señalar que esta es una configuración basada en anotaciones , @Repositoryel trabajo es capturar excepciones específicas de la plataforma y volver a lanzarlas como una de las excepciones unificadas y no verificadas de Spring. Para esto, se nos proporciona PersistenceExceptionTranslationPostProcessorque debemos agregar en el contexto de nuestra aplicación Spring de esta manera:
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
Este postprocesador de beans agrega un asesor a cualquier bean anotado @Repositorypara que se capturen las excepciones específicas de la plataforma y luego se vuelvan a generar como una de las excepciones de acceso a datos no verificadas de Spring.
@Controlador
La @Controlleranotación indica que una clase particular cumple la función de un controlador. La @Controlleranotación actúa como un estereotipo para la clase anotada, indicando su papel.
¿Qué tiene de especial @Controller?
No podemos cambiar esta anotación con ninguna otra similar @Serviceo @Repository, aunque parezcan iguales. El despachador escanea las clases anotadas @Controllery detecta métodos anotados con @RequestMappinganotaciones dentro de ellas. Podemos utilizar @RequestMappingsobre / en sólo aquellos métodos cuyas clases están anotados con @Controllery será NO trabajar con @Component, @Service, @Repositoryetc ...
Nota: Si una clase ya está registrado como un bean a través de cualquier método alternativo, al igual que a través @Beano por medio de @Component, @Serviceetc ... anotaciones, a continuación, @RequestMappingse pueden tomar si la clase también se anota con @RequestMappinganotación. Pero ese es un escenario diferente.
@Servicio
@Service los beans contienen la lógica de negocios y los métodos de llamada en la capa del repositorio.
¿Qué tiene de especial @Service?
Aparte del hecho de que se usa para indicar, que mantiene la lógica de negocios, no hay nada más notable en esta anotación; pero quién sabe, Spring puede agregar algunos excepcionales adicionales en el futuro.
¿Qué más?
Similar a lo anterior, en el futuro Spring puede agregar funcionalidades especiales para @Service, @Controllery en @Repositorybase a sus convenciones de capas. Por lo tanto, siempre es una buena idea respetar la convención y usarla en línea con las capas.
