Могут ли @Component, @Repository и @Service аннотации использоваться взаимозаменяемо в Spring или они обеспечивают какую-либо конкретную функциональность, помимо того, что действуют как устройство нотации?
Другими словами, если у меня есть класс Service, и я изменяю аннотацию от @Service до @Component, будет ли он по-прежнему вести себя одинаково?
Или аннотация также влияет на поведение и функциональность класса?
В Spring 2.0 и более поздних
@Repositoryаннотация@Repositoryявляется маркером для любого класса, который выполняет роль или стереотип (также известный как объект доступа к данным или DAO) хранилища. Среди применений этого маркера - автоматический перевод исключений.В Spring 2.5
@Componentдополнительные аннотации стереотипов:@Component,@Serviceи@Controller.@Component- это общий стереотип для любого компонента, управляемого Spring.@Repository,@Serviceи@Controllerявляются специализациями@Componentдля более конкретных случаев использования, например, на уровнях постоянства, обслуживания и представления соответственно.Таким образом, вы можете аннотировать классы компонентов с помощью
@Component, но, вместо этого, аннотируя их с помощью@Repository,@Serviceили@Controller, ваши классы лучше подходят для обработки инструментами или связи с аспектами. Например, эти аннотации стереотипов делают идеальные цели для pointcut.Таким образом, если вы выбираете между использованием
@Componentили@Serviceдля своего уровня обслуживания,@Service,@Serviceявляется лучшим выбором. Точно так же, как указано выше,@Repositoryуже поддерживается в качестве маркера для автоматического преобразования исключений в вашем слое постоянства.
┌────────────┬─────────────────────────────────────────────────────┐
│ Annotation │ Meaning │
├────────────┼─────────────────────────────────────────────────────┤
│ @Component │ generic stereotype for any Spring-managed component │
│ @Repository│ stereotype for persistence layer │
│ @Service │ stereotype for service layer │
│ @Controller│ stereotype for presentation layer (spring-mvc) │
└────────────┴─────────────────────────────────────────────────────┘
Поскольку во многих ответах уже указано, для чего используются эти аннотации, мы сосредоточимся здесь на некоторых незначительных различиях между ними.
Первое сходство
Еще один момент, на который стоит обратить внимание: автоматическое обнаружение сканирования и внедрение зависимостей для BeanDefinition все эти аннотации (а именно, @Component, @Service, @Repository, @Controller) одинаковы. Мы можем использовать одно вместо другого и все еще обойтись.
@Составная часть
Это универсальная аннотация стереотипа, указывающая, что класс является компонентом Spring.
Что особенного в @Component <context:component-scan> сканирует только @Component и вообще не ищет @Controller, @Service и @Repository. Они сканируются, потому что сами @Component.
Просто взгляните на определения аннотаций @Controller, @Service и @Repository:
@Component
public @interface Service {
….
}
@Component
public @interface Repository {
….
}
@Component
public @interface Controller {
…
}
Таким образом, нет ничего плохого в том, что @Controller, @Service и @Repository являются особыми типами аннотации @Component. <context:component-scan> подбирает их и регистрирует их следующие классы как @Component, как если бы они были аннотированы @Component.
Аннотации специальных типов также сканируются, потому что они сами @Component аннотацией @Component, что означает, что они также являются @Component s. Если мы определим нашу собственную пользовательскую аннотацию и аннотируем ее с помощью @Component, она также будет сканироваться с помощью <context:component-scan>
@Repository
Это указывает на то, что класс определяет хранилище данных.
Что особенного в @Repository?
В дополнение к указанию, что это конфигурация на основе аннотаций, задание @Repository должно перехватывать специфичные для платформы исключения и повторно @Repository их как одно из унифицированных непроверенных исключений Springs. Для этого были предоставлены PersistenceExceptionTranslationPostProcessor, которые мы должны добавить в контекст приложения Springs следующим образом:
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
Этот @Repository бина добавляет советник к любому @Repository аннотированному @Repository так что любые специфичные для платформы исключения перехватываются и затем перебрасываются как одно из исключений доступа к данным, не проверенных Springs.
@Controller
Аннотация @Controller указывает, что определенный класс выполняет роль контроллера. Аннотация @Controller действует как стереотип для аннотированного класса, указывая на его роль.
Что особенного в @Controller?
Мы не можем поменять эту аннотацию на любую другую, такую как @Service или @Repository, даже если они выглядят одинаково. Диспетчер просматривает классы, аннотированные @Controller и обнаруживает методы, аннотированные аннотациями @RequestMapping внутри них. Мы можем использовать @RequestMapping только для тех методов, классы которых аннотированы с помощью @Controller и они НЕ будут работать с @Component, @Service, @Repository т.д....
Примечание. Если класс уже зарегистрирован как компонент с помощью какого-либо альтернативного метода, например, с помощью @Bean или @Component, @Service т.д...., то @RequestMapping можно выбрать, если класс также аннотирован аннотацией @RequestMapping.Но это другой сценарий.
@Обслуживание
@Service содержат бизнес-логику и вызывают методы на уровне хранилища.
Что особенного в @Service?
Помимо того факта, что он имел обыкновение указывать, что он содержит бизнес-логику, в этой аннотации нет ничего более заметного; но кто знает, spring может добавить некоторые дополнительные исключительные в будущем.
Что-то еще?
Как и выше, в будущем Spring может добавить специальные функции для @Service, @Controller и @Repository с их соглашениями о размещении. Следовательно, всегда полезно соблюдать соглашение и использовать его в соответствии со слоями.
Они почти одинаковы - все они означают, что класс Spring bean. @Service, @Repository и @Controller являются специализированными @Component s. Вы можете выполнять определенные действия с ними. Например:
@Controller beans используются spring -mvc@Repository beans имеют право на перенос исключений персистентностиДругое дело, что вы назначаете компоненты семантически для разных слоев.
Одна вещь, которую предлагает @Component, состоит в том, что вы можете аннотировать другие аннотации с ней, а затем использовать их так же, как @Service.
Например, недавно я сделал:
@Component
@Scope("prototype")
public @interface ScheduledJob {..}
Таким образом, все классы, аннотированные с помощью @ScheduledJob, являются Spring beans и в дополнение к ним регистрируются как задания кварца. Вам просто нужно предоставить код, который обрабатывает конкретную аннотацию.
@Компонент эквивалентен
<bean>
@Service, @Controller, @Repository = {@Component + еще одна специальная функция}
Это означает, что Сервис, Контроллер и Репозиторий функционально одинаковы.
Три аннотации используются для разделения "Слои" в вашем приложении,
Теперь вы можете спросить, зачем их разделять: (я полагаю, вы знаете AOP-Aspect Oriented Programming)
Предположим, вы хотите отслеживать только активность слоя DAO. Вы напишете класс Aspect (A class), который выполняет некоторую регистрацию до и после каждого метода вашего DAO, вы можете сделать это с помощью AOP, поскольку у вас есть три разных слоя и не смешиваются.
Таким образом, вы можете выполнять протоколирование DAO "вокруг", "до" или "после" методов DAO. Вы могли бы это сделать, потому что у вас был DAO в первую очередь. То, что вы только что достигли, - это Разделение проблем или задач.
Представьте себе, что если есть только одна аннотация @Controller, тогда этот компонент будет иметь диспетчерскую, бизнес-логику и доступ к базе данных, все смешанные, так грязные коды!
Вышеупомянутый - один очень распространенный сценарий, есть еще много примеров использования трех аннотаций.
В Spring @Component, @Service, @Controller и @Repository являются аннотациями стереотипа, которые используются для:
@Controller: когда выполняется сопоставление вашего запроса со страницы презентации, т.е. Слой Presentation не переходит в какой-либо другой файл, он идет непосредственно в класс @Controller и проверяет запрошенный путь в аннотации @RequestMapping которая записывается перед вызовами метода, если это необходимо.
@Service: здесь присутствует вся бизнес-логика, т.е. расчеты, связанные с данными, и все. Это аннотация бизнес-уровня, в которой наш пользователь напрямую не вызывает метод постоянства, поэтому он будет вызывать этот метод с помощью этой аннотации. Он будет запрашивать @Repository согласно запросу пользователя
@Repository: это постоянный уровень (Data Access Layer) приложения, который используется для получения данных из базы данных. т.е. все связанные с базой данных операции выполняются хранилищем.
@Component - Аннотируйте ваши другие компоненты (например, классы ресурсов REST) со стереотипом компонента.
Указывает, что аннотированный класс является " компонентом ". Такие классы рассматриваются как кандидаты на автоопределение при использовании конфигурации на основе аннотаций и сканирования пути к классам.
Другие аннотации уровня класса также могут рассматриваться как идентифицирующие компонент, обычно это особый вид компонента: например, аннотация @Repository или аннотация AspectJ @Aspect.
Spring 2.5 вводит дополнительные аннотации стереотипов: @Component, @Service и @Controller. @Component служит общим стереотипом для любого компонента, управляемого Spring; в то время как @Repository, @Service и @Controller служат специализациями @Component для более конкретных случаев использования (например, на уровнях постоянства, обслуживания и представления соответственно). Это означает, что вы можете аннотировать свои классы компонентов с помощью @Component, но, вместо этого, аннотируя их с помощью @Repository, @Service или @Controller, ваши классы лучше подходят для обработки инструментами или связи с аспектами. Например, эти аннотации стереотипов делают идеальные цели для pointcut. Конечно, также возможно, что @Repository, @Service и @Controller могут нести дополнительную семантику в будущих выпусках Spring Framework. Таким образом, если вы принимаете решение между использованием @Component или @Service для своего уровня обслуживания, @Service, безусловно, является лучшим выбором. Точно так же, как указано выше, @Repository уже поддерживается в качестве маркера для автоматического преобразования исключений в вашем слое постоянства.
@Component – Indicates a auto scan component. @Repository – Indicates DAO component in the persistence layer. @Service – Indicates a Service component in the business layer. @Controller – Indicates a controller component in the presentation layer.
@Component – Indicates a auto scan component.
@Repository – Indicates DAO component in the persistence layer.
@Service – Indicates a Service component in the business layer.
@Controller – Indicates a controller component in the presentation layer.
Вы заметите, что все @Repository, @Service или @Controller аннотируются с помощью @Component. Итак, можно ли использовать только @Component для всех компонентов для автоматического сканирования? Да, вы можете, и Spring будет автоматически сканировать все ваши компоненты с помощью @Component, аннотированных.
Его работа прекрасна, но не очень хорошая практика, для удобства чтения вы всегда должны объявлять @Repository, @Service или @Controller для заданного уровня, чтобы сделать ваш код более понятным для чтения.
Использование аннотаций @Service и @Repository важно с точки зрения подключения к базе данных.
@Service для всех типов веб-служб соединений с БД.@Repository для всех сохраненных соединений proc DBЕсли вы не используете соответствующие аннотации, вы можете столкнуться с исключениями, отмененными транзакциями отката. Вы увидите исключения во время теста нагрузочной нагрузки, связанные с откатными транзакциями JDBC.
Разница между @Component, @Service и @Repository
Основное различие между этими стереотипами заключается в том, что они используются для различной классификации.
В многоуровневом приложении у нас будут разные уровни, такие как презентация, обслуживание, бизнес, доступ к данным и т.д. Когда класс должен быть аннотирован для автоматического обнаружения с помощью Spring, тогда мы должны использовать соответствующий стереотип, как показано ниже.
@Component - общий и может использоваться во всех приложениях. @Service - аннотировать классы на уровне уровня сервиса. @Repository - аннотировать классы на уровне персистентности, которые будут выступать в качестве репозитория базы данных.
Если технически они будут одинаковыми, то зачем нам их использовать на разных уровнях. Почему бы не использовать одно и то же на всех уровнях. Например, если мы используем @Service во всех слоях, все beans получат экземпляр и никаких проблем. Существует незначительная разница, например, рассмотрим @Repository.
Постпроцессор автоматически ищет все интерпретаторы исключений (реализации интерфейса PersistenceExceptionTranslator) и сообщает всем beans, помеченным аннотацией @Repository, чтобы обнаруженные переводчики могли перехватывать и применять соответствующий перевод на заброшенные исключения.
Как и в предыдущем случае, в будущем Spring может выбрать значение для @Service, @Controller и @Repository в соответствии с их соглашениями о выравнивании. К этому дополнительному преимуществу преимущество лучше соблюдать соглашение и использовать их в соответствии со слоями.
Помимо вышеперечисленного, в отношении сканирования-автоматического обнаружения инъекция зависимостей для BeanDefinition @Component, @Service, @Repository, @Controller одинакова.
Технически @Controller, @Service, @Repository все одинаковы. Все они расширяются @Component.
Из исходного кода Spring:
Указывает, что аннотированный класс является "компонентом". Такие классы рассматриваются как кандидаты для автоматического обнаружения при использовании конфигурации на основе аннотаций и сканирования пути к классам.
Мы можем напрямую использовать @Component для каждого компонента, но для лучшего понимания и поддержки больших приложений мы используем @Controller, @Service, @Repository.
Назначение каждой аннотации:
@Controller → Классы, аннотированные этим, предназначены для получения запроса со стороны клиента. Первый запрос поступает в сервлет Dispatcher, откуда он передает запрос конкретному контроллеру, используя значение аннотации @RequestMapping.@Service → Классы, аннотированные этим, предназначены для манипулирования данными, которые мы получаем от клиента или выбираем из базы данных. Все манипуляции с данными должны быть выполнены в этом слое.@Repository → Классы, аннотированные этим, предназначены для соединения с базой данных. Его также можно рассматривать как уровень DAO (объекта доступа к данным). Этот уровень должен быть ограничен только операциями CRUD (создание, получение, обновление, удаление). Если требуются какие-либо манипуляции, данные должны быть отправлены обратно на уровень @Service. Если мы @Repository местами (используйте @Repository вместо @Controller), наше приложение будет работать нормально.
Основная цель использования трех различных @annotations - обеспечить лучшую модульность для приложения Enterprise.
@Repository @Service и @Controller служат специализацией @Component для более конкретного использования на этой основе, вы можете заменить @Service на @Component, но в этом случае вы теряете специализацию.
1. **@Repository** - Automatic exception translation in your persistence layer.
2. **@Service** - It indicates that the annotated class is providing a business service to other layers within the application.
все эти аннотации являются типом аннотации типа стерео-типа, разница между этими тремя аннотациями
- Если мы добавим @Component, тогда он говорит, что роль класса является классом компонентов, это означает, что это класс, состоящий из некоторой логики, но он не указывает, относится ли класс, содержащий конкретный бизнес или настойчивость или логику контроллера, поэтому мы не используем непосредственно это @Компонентная аннотация
- Если мы добавим аннотацию @Service, тогда она сообщит, что роль класса, состоящего из бизнес-логики
- Если мы добавим @Repository поверх класса, тогда он сообщает, что класс, содержащий логику сохранения
- Здесь @Component - это базовая аннотация для аннотаций @Service, @Repository и @Controller.
например
package com.spring.anno;
@Service
public class TestBean
{
public void m1()
{
//business code
}
}
package com.spring.anno;
@Repository
public class TestBean
{
public void update()
{
//persistence code
}
}
@Service или @Repositroy или @Controller по умолчанию @Component, аннотация будет существовать поверх класса Spring предоставляет четыре различных типа аннотаций автоматического сканирования компонентов: @Component, @Service, @Repository и @Controller. Технически, между ними нет никакой разницы, но каждую аннотацию автоматического сканирования компонентов следует использовать для специальных целей и в пределах определенного слоя.
@Component: это базовая аннотация автоматического сканирования компонентов, она указывает, что аннотированный класс является компонентом автоматического сканирования.
@Controller: аннотированный класс указывает, что он является компонентом контроллера и в основном используется на уровне представления.
@Service: указывает, что аннотированный класс является компонентом Service на бизнес-уровне.
@Repository: вам нужно использовать эту аннотацию в слое постоянства, это действует как хранилище базы данных.
Нужно выбрать более специализированную форму @Component при аннотировании их класса, так как эта аннотация может содержать определенное поведение в будущем.
Мы можем ответить на это в соответствии со стандартом Java
Что касается JSR-330, который теперь поддерживается @Named, вы можете использовать только @Named для определения компонента (@Named @[email protected]). Таким образом, в соответствии с этим стандартом кажется, что нет смысла определять стереотипы (такие как @Repository, @Service, @Controller) для категорийных компонентов.
Но spring пользователь эти разные аннотации по-разному для конкретного использования, например:
aspect-oriented, они могут быть хорошим кандидатом для создания pointcuts)@Repository добавит некоторую функциональность вашему бину (некоторая автоматическая трансляция исключений для вашего уровня персистентности бина).@RequestMapping MVC, @RequestMapping можно добавлять только к классам, аннотированным @Controller.Аннотируйте другие компоненты с помощью @Component, например, классы REST Resource.
@Component
public class AdressComp{
.......
...//some code here
}
@Component - это общий стереотип для любого управляемого компонента Spring.
@Controller, @Service и @Repository являются специализациями @Component для конкретных случаев использования.
В многоуровневом приложении у нас будут разные уровни, такие как презентация, обслуживание, бизнес, доступ к данным и т.д. Когда класс должен быть аннотирован для автоматического обнаружения с помощью Spring, тогда мы должны использовать соответствующий стереотип, как показано ниже.
Даже если мы меняем @Component или @Repository или @service
Он будет вести себя одинаково, но один аспект заключается в том, что они не смогут поймать какое-то конкретное исключение, связанное с DAO, а не с репозиторием, если мы используем компонент или @service
В Spring 4, последняя версия:
Аннотирование @Repository является маркером для любого класса, который выполняет роль или стереотип репозитория (также известный как объект доступа к данным или DAO). Среди применений этого маркера - автоматический перевод исключения, как описано в Разделе 20.2.2, "Перевод исключений".
Spring предоставляет дополнительные аннотации к стереотипам: @Component, @Service, и @Controller. @Component - общий стереотип для любого Spring - управляемый компонент. @Repository, @Service и @Controller - специализации @Component для более конкретных случаев использования, для например, в уровнях персистентности, обслуживания и представления, соответственно. Поэтому вы можете комментировать классы компонентов с помощью @Component, но аннотируя их с помощью @Repository, @Service или @Controller вместо этого, ваши классы более подходят для обработки инструментами или связывания с аспектами. Например, эти аннотации стереотипов создают идеальные цели для pointcut. Это также возможно, что @Repository, @Service и @Controller могут нести дополнительную семантику в будущих выпусках Spring Framework. Таким образом, если вы выбираете между использованием @Component или @Service для своего сервисный уровень, @Service, безусловно, лучший выбор. Аналогично, поскольку выше, @Repository уже поддерживается как маркер для автоматический перевод исключений в вашем уровне персистентности.
1. Основное различие между этими стереотипами заключается в том, что они используются для различной классификации.
2. В многоуровневом приложении у нас будут разные уровни, такие как презентация, обслуживание, бизнес, доступ к данным и т.д. Когда класс должен быть аннотирован для автоматического обнаружения с помощью Spring, тогда мы должны использовать соответствующий стереотип как ниже.
@Component - общий и может использоваться в приложении.@Service - аннотировать классы на уровне уровня сервиса.@Controller - аннотировать классы на уровне уровней представления, в основном используемые в Spring MVC.@Repository - аннотировать классы на уровне персистентности, которые будут выступать в качестве репозитория базы данных. Если технически они будут одинаковыми, то зачем нам их использовать на разных уровнях. Почему бы не использовать одно и то же на всех уровнях. Например, если мы используем @Service во всех слоях, все beans получат экземпляр и никаких проблем. Существует незначительная разница, например, рассмотрим @Repository.Постпроцессор автоматически ищет всех переводчиков исключений (реализация интерфейса PersistenceExceptionTranslator) и рекомендует все beans, помеченные аннотацией @Repository, чтобы обнаруженные переводчики могут перехватывать и применять соответствующие перевод на заброшенные исключения.
@Service, @Controller и @Repository на основе их расслоения
конвенций. К этому дополнительному преимуществу лучше
соблюдать соглашение и использовать их в соответствии со слоями.@Component, @Service, @Repository,
@Controller совпадают.Spring @Component, @Service, @Repository и @Controller аннотации используются для автоматического обнаружения bean с помощью сканирования пути к классам в Spring.
@Компонент - это общая аннотация. Разница @Service, @Repository, @Controller с @Component - это особые случаи @Component и используются для определенных целей. Разница только в классификации.
Для всех этих аннотаций (стереотипов) технически основная цель та же. Spring автоматически сканирует и идентифицирует все эти классы, которые аннотируются с помощью "@Component, @Service, @Repository, @Controller" и регистрирует bean Определение с помощью ApplicationContext.
Нет никакой разницы между @Component, @Service, @Controller, @Repository. @Component - это общая аннотация для представления компонента нашего MVC. Но в составе нашего MVC-приложения будут использоваться несколько компонентов, таких как компоненты уровня обслуживания, компоненты уровня persistence и компоненты уровня представления. Поэтому, чтобы различать их, люди также дали три других аннотации.
Представить компоненты уровня сохранения: @Repository
Чтобы представить компоненты уровня сервиса: @Service
Представление компонентов уровня представления: @Controller
иначе вы можете использовать @Component для всех из них.
@Component - это общая аннотация верхнего уровня, которая позволяет сканировать аннотированный компонент и быть доступным в контейнере DI.
@Repository - это специализированная аннотация, в которой реализована возможность преобразования всех непроверенных исключений из классов DAO.
@Service - это специализированная аннотация. это не приносит никакой новой функции на данный момент, но это проясняет намерение бина
@Controller - это специализированная аннотация, которая информирует MVC о компоненте и позволяет использовать дополнительную аннотацию, такую как @RequestMapping и все подобные
Вот больше подробностей
A @Service, чтобы представить документацию spring,
Указывает, что аннотированный класс представляет собой "Сервис", изначально определенный (Evans, 2003) как "операция, предлагаемая в качестве интерфейс, который стоит отдельно в модели, без инкапсулированного состояния." Также может указывать, что класс является "Facility Business Facade" (в Core J2EE) или что-то подобное. Эта аннотация является стереотип общего назначения и отдельные команды могут семантики и использовать по мере необходимости.
Если вы посмотрите на проект, основанный на домене, с помощью eric evans,
Служба SERVICE - это операция, предлагаемая в качестве интерфейса, который модель, без инкапсулирующего состояния, как ОБЪЕКТЫ И ОБЪЕКТЫ ОБЪЕКТОВ делать. УСЛУГИ являются общей моделью в технических рамках, но они может также применяться в доменном слое. Служба имен подчеркивает отношения с другими объектами. В отличие от ОБЪЕКТОВ и ОБЪЕКТОВ VALUE, это определяется исключительно с точки зрения того, что он может сделать для клиента. СЕРВИС имеет тенденцию обозначаться как активность, а не сущность - скорее глагол чем существительное. СЕРВИС все еще может иметь абстрактный, преднамеренный определение; у него просто отличный вкус, чем определение объект. У ОБСЛУЖИВАНИЯ все еще должна быть определенная ответственность, и что ответственность и выполняемый интерфейс должны быть определены как частью модели домена. Названия операций должны поступать из UBIQUITOUS LANGUAGE или быть введенным в него. Параметры и результаты должны быть объектами домена. УСЛУГИ следует использовать разумно, а не позволили снять объекты ENTITIES и VALUE всех своих действий. Но когда операция на самом деле является важной концепцией домена, СЕРВИС является естественной частью МОДЕЛЬ-ДВИЖЕНИЯ. Объявлено в модель как СЕРВИС, а не как фальшивый объект, который не фактически представляют что-либо, автономная операция не вводит в заблуждение кто угодно.
и a Repository в соответствии с Эриком Эвансом,
A REPOSITORY представляет все объекты определенного типа как концептуальные set (обычно эмулируется). Он действует как коллекция, за исключением большего количества уточнить возможности запросов. Объектами соответствующего типа являются добавлены и удалены, а оборудование за вкладками REPOSITORY их или удаляет из базы данных. Это определение собирает сплоченный набор обязанностей для обеспечения доступа к корням AGGREGATES от раннего жизненного цикла до конца.
@Component: вы комментируете класс @Component, он сообщает hibernate, что это Bean.
@Repository: вы комментируете класс @Repository, он говорит, что спящий режим является классом DAO и рассматривает его как класс DAO. Означает, что он делает исключенные исключения (брошенные из методов DAO), подходящие для перевода в Spring DataAccessException.
@Service. Это говорит о спящем режиме, это класс службы, в котором у вас будут @Transactional и т.д. Аннотации уровня сервиса, поэтому hibernate рассматривает его как компонент службы.
Плюс @Сервис - продвижение @Component. Предположим, что имя класса bean - CustomerService, так как вы не выбрали конфигурацию XML bean, поэтому вы аннотировали bean с @Component, чтобы указать ее как Bean. Таким образом, при получении объекта bean CustomerService cust = (CustomerService)context.getBean("customerService"); По умолчанию Spring приведет к уменьшению случая первого символа компонента - от CustomerService до customerService. И вы можете получить этот компонент с именем "customerService".
Но если вы используете аннотацию @Service для класса bean, вы можете указать конкретное имя bean
@Service("AAA")
public class CustomerService{
и вы можете получить объект bean
CustomerService cust = (CustomerService)context.getBean("AAA");
Репозиторий и Сервис являются дочерними компонентами аннотации Компонента. Итак, все они являются Компонентом. Репозиторий и Сервис просто расширяют его. Как именно? Сервис имеет только идеологическое отличие: мы используем его для сервисов. Репозиторий имеет особый обработчик исключений.
Объяснение стереотипов:
@Service - @Service все свои классы обслуживания с помощью @Service. Этот слой знает единицу работы. Вся ваша бизнес-логика будет в классах обслуживания. Обычно методы сервисного уровня покрываются транзакцией. Вы можете сделать несколько вызовов DAO из метода сервиса, если одна транзакция не удалась, все транзакции должны быть откатаны.@Repository - Аннотируйте все ваши классы DAO с помощью @Repository. Вся логика доступа к вашей базе данных должна быть в классах DAO.@Component - Аннотируйте ваши другие компоненты (например, классы ресурсов REST) со стереотипом компонента.@Autowired - пусть Spring автоматически @Autowired другие bean-компоненты к вашим классам, используя аннотацию @Autowired. @Component - это общий стереотип для любого компонента, управляемого Spring. @Repository, @Service и @Controller являются специализациями @Component для более конкретных случаев использования, например, на уровнях постоянства, обслуживания и представления соответственно.
Первоначально ответил здесь.
@Component, @Репозиторий, @Сервис, @Controller:
@Component - это общий стереотип для компонентов, управляемых Spring @Repository, @Service и @Controller являются специализациями @Component для более конкретного использования:
Зачем использовать @Repository, @Service, @Controller вместо @Component? Мы можем пометить наши классы компонентов с помощью @Component, но если вместо этого мы используем альтернативу, которая адаптируется к ожидаемой функциональности. Наши классы лучше подходят для функциональности, ожидаемой в каждом конкретном случае.
Класс, аннотированный @Repository, имеет лучший перевод и удобочитаемую обработку ошибок с помощью org.springframework.dao.DataAccessException. Идеально подходит для реализации компонентов, которые обращаются к данным (DataAccessObject или DAO).
Аннотированный класс с "@Controller" играет роль контроллера в приложении Spring Web MVC
Аннотированный класс с "@Service" играет роль в сервисах бизнес-логики, например, шаблон Facade для DAO Manager (Facade) и обработка транзакций.
В фреймворке Spring предоставляется особый тип аннотаций, называемый аннотациями стереотипов. Это следующие: -
@RestController- Declare at controller level.
@Controller – Declare at controller level.
@Component – Declare at Bean/entity level.
@Repository – Declare at DAO level.
@Service – Declare at BO level.
объявленные выше аннотации являются особыми, потому что когда мы добавляем <context:component-scan> в файл xxx-servlet.xml, Spring автоматически создает объект тех классов, которые аннотируются вышеуказанной аннотацией на этапе создания/загрузки контекста.
Чтобы упростить эту иллюстрацию, давайте рассмотрим техническую специфику в зависимости от случая использования. Эти аннотации используются для инъекции, и, как я сказал буквально "Используется для инъекции", это означает, что если вы знаете, как использовать Dependency Injection "DI", и вы Если вы всегда будете искать эти аннотации, и, аннотируя классы этими стерео-типами, вы сообщаете контейнеру DI о необходимости сканировать их, чтобы они были готовы к инъекции в других местах, это практическая цель.
Теперь давайте перейдем к каждому; first @Service, если вы создаете некоторую логику для конкретного бизнес-кейса, вам нужно отделить ее в месте, где будет содержаться ваша бизнес-логика, этот сервис является обычным классом или вы можете использовать его как интерфейс, если хотите, и он написан так: этот
@Service
public class Doer {
// Your logic
}
// To use it in another class, suppose in Controller
@Controller
public class XController {
// You have to inject it like this
@Autowired
private Doer doer;
}
Все они одинаковы, когда вы вводите их, @Repository это интерфейс, который применяет реализацию шаблона проектирования Repository Pattern Repository, обычно он используется, когда вы имеете дело с каким-то хранилищем данных или базой данных, и вы обнаружите, что он содержит несколько готовая реализация для обработки операций с базой данных; это может быть CrudRepository, JpaRepository и т.д.
// For example
public interface DoerRepository implements JpaRepository<Long, XEntity> {}
Наконец, @Component, это обобщенная форма для зарегистрированных bean-компонентов в Spring, которая всегда ищет bean-компонент, помеченный @Component, для регистрации, тогда и @Service, и @Repository являются частными случаями @Component, однако это частый случай использования. Компонент - это когда вы делаете что-то чисто техническое, а не для прямого бизнес-кейса! как форматирование дат или передача специального механизма сериализации запросов и так далее.
Достаточно хороших ответов здесь, чтобы объяснить
@Controller против RestController@RestController: 
@Controller которая @Controller @ResponseBody аннотации @Controller и @ResponseBody. поэтому нам не нужно добавлять @ResponseBody в наши методы отображения. Это означает, что @ResponseBody по умолчанию активен.@RestController вы не сможете вернуть представление (с помощью Viewresolver в Spring/Spring-Boot)@RestController также @RestController преобразует ответ в JSON/XML automatically поскольку @ResponseBody превращает возвращаемые объекты во что-то, что может находиться в теле, eg JSON or XML@Controller 
@Controller используется для обозначения классов как Spring MVC Controller. Эта аннотация является специализированной версией @Component и позволяет автоматически определять классы контроллера на основе сканирования пути к классам.@Controller вы можете вернуть представление в Spring Web MVC.