Чтобы упростить эту иллюстрацию, давайте рассмотрим техническую специфику в зависимости от случая использования. Эти аннотации используются для инъекции, и, как я сказал буквально « Раньше для инъекции », это означает, что если вы знаете, как использовать 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 это интерфейс, который применяет реализацию для шаблона репозитория Шаблон проектирования репозитория , обычно он используется, когда вы имеете дело с некоторое хранилище данных или базу данных, и вы обнаружите, что оно содержит несколько готовых реализаций для обработки операций с базой данных; это может быть CrudRepository , JpaRepository и т. д.
// For example
public interface DoerRepository implements JpaRepository<Long, XEntity> {}
Наконец, @ Component , это обобщенная форма для зарегистрированных bean-компонентов в Spring, то есть spring всегда ищет bean-компонент, отмеченный @Component, для регистрации, тогда и @Service, и @Repository являются особыми случаями. @Component, однако, общий вариант использования компонента - это когда вы делаете что-то чисто техническое, а не для прямого бизнес-случая! например, форматирование дат или передача специального механизма сериализации запросов и т. д.