Поскольку во многих ответах уже указано, для чего используются эти аннотации, мы сосредоточимся здесь на некоторых незначительных различиях между ними.
Сначала Сходство
Первое, на что следует обратить внимание, это то, что в отношении автоматического обнаружения сканирования и внедрения зависимостей для BeanDefinition всех этих аннотаций (а именно, @Component, @Service,
@Repository, @Controller) одинаковы. Мы можем использовать один на месте
другого и все еще может разобраться.
Различия между @Component, @Repository, @Controller и @ Service
@ Компонент
Это универсальная аннотация стереотипа, указывающая на то, что класс является пружинным компонентом.
Что особенного в @ Component
<context:component-scan>
только сканирует @Component
и не ищет @Controller
, @Service
и @Repository
в целом. Они сканируются, потому что сами помечены @Component
.
Просто взгляните на определения аннотаций @Controller
, @Service
и @Repository
:
@Component
public @interface Service {
….
}
1045 *
@Component
public @interface Repository {
….
}
1048 *
@Component
public @interface Controller {
…
}
Таким образом, не ошибочно говорить, что @Controller
, @Service
и @Repository
- это особые типы @Component
аннотаций. <context:component-scan>
подбирает их и регистрирует их следующие классы как бины, как если бы они были помечены @Component
.
Аннотации специального типа также сканируются, поскольку сами они снабжены аннотацией @Component
, что означает, что они также @Component
с. Если мы определим нашу собственную пользовательскую аннотацию и аннотируем ее с помощью @Component
, она также будет сканироваться с помощью <context:component-scan>
@ Repository
Это указывает на то, что класс определяет хранилище данных.
Что особенного в @Repository?
В дополнение к указанию, что это Конфигурация на основе аннотаций , задача @Repository
состоит в том, чтобы перехватывать специфичные для платформы исключения и повторно выдавать их как одно из унифицированных непроверенных исключений Spring. Для этого нам предоставляется PersistenceExceptionTranslationPostProcessor
, который мы должны добавить в контекст приложения Spring, например:
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
Этот постпроцессор бина добавляет советник для любого бина, помеченного @Repository
, так что любые специфичные для платформы исключения перехватываются, а затем повторно выбрасываются как одно из исключений Spring для непроверенного доступа к данным.
@ контроллер
Аннотация @Controller
указывает, что определенный класс выполняет роль контроллера. Аннотация @Controller
выступает в качестве стереотипа для аннотированного класса, указывая его роль.
Что особенного в @Controller?
Мы не можем поменять эту аннотацию на любую другую, например @Service
или @Repository
, даже если они выглядят одинаково.
Диспетчер сканирует классы, помеченные @Controller
, и обнаруживает методы, помеченные аннотациями @RequestMapping
. Мы можем использовать @RequestMapping
только в тех методах, классы которых отмечены @Controller
, и он будет НЕ работать с @Component
, @Service
, @Repository
и т. Д.
Примечание. Если класс уже зарегистрирован как компонент с помощью какого-либо альтернативного метода, например, с помощью @Bean
или @Component
, @Service
и т. Д. ..., тогда @RequestMapping
выбирается, если класс также помечен аннотацией @RequestMapping
. Но это другой сценарий.
@ Service
@Service
bean-компоненты содержат бизнес-логику и вызывают методы на уровне хранилища.
Что особенного в @Service?
Помимо того факта, что он используется для обозначения того, что он содержит бизнес-логику, в этой аннотации больше ничего не заметно; но кто знает, Spring может добавить еще несколько исключительных в будущем.
Что еще?
Как и выше, вбудущая весна может добавить специальные функции для @Service
, @Controller
и @Repository
на основе их соглашений о наложении слоев. Следовательно, всегда полезно соблюдать соглашение и использовать его в соответствии со слоями.