Архитектура кода интерфейса сервисов и классов обслуживания spring

Я обнаружил, что в паттерне MVC в основном 4 класса; Контроллер, сервис, сервис импл и репо.

Сервис - это интерфейс, а сервис реализует класс сервиса и содержит все логические коды. Структура будет выглядеть примерно так: -

Интерфейс Service

Service{

public void someMethod();

}

ServiceImpl класс

 ServiceImpl implements Service{
  public void someMethod(){
   //do something

   }    
 }

Но когда мы хотим получить доступ к кодам обслуживания с контроллера, мы вызываем метод класса обслуживания как: -

@Autowired 
Service service;

Object obj =  service.someMethod();

Как контроллер выполняет код класса ServiceImpl

Ответ 1

Вот как в основном работает Spring:

Реализация службы должна быть компонентом Spring (она должна иметь аннотацию @Component или @Service или должна быть определена в файле конфигурации Spring XML), чтобы Spring мог найти ее и зарегистрировать в контексте приложения Spring.

Затем вы используете внедрение зависимостей через аннотацию @Autowired, чтобы внедрить реализацию сервиса в контроллер. Это означает, что Spring будет смотреть на ваш контроллер, он найдет аннотацию @Autowired в переменной-члене service и инициализирует ее с помощью bean-компонента, @Autowired в контексте приложения, который будет экземпляром класса реализации службы, который он зарегистрировал. ранее. Таким образом, после завершения Spring service будет ссылаться на экземпляр ServiceImpl.

См. Справочную документацию Spring Framework для получения информации о том, как внедрение зависимостей работает с Spring: контейнер IoC

Ответ 2

Основная идея, лежащая в основе такой архитектуры, мало чем отличается от весеннего соглашения.

Допустим, завтра вы решите, что вы не хотите иметь одно приложение для обоих проектов и перейдете в одно развертывание для веб-приложения и другое для службы. Пример UserService WebApp

поэтому, чтобы WebApp мог подключиться к UserService, ему нужно будет выполнить http-запросы для получения любых данных. тогда вам придется изменить весь ваш код WebApp, чтобы сделать его совместимым с новыми изменениями. Например, вместо прямого вызова метода Service вы будете вызывать httpClient. Чтобы избежать этой переделки, вы можете использовать интерфейс службы, используя свой собственный ServiceImpl и делать там все http-запросы, остальное остается нетронутым.

Подобные вещи будут выполнены в UserService, он будет иметь свой собственный ServiceImpl, как и раньше, но будет вызываться в Controller как одноэлементный объект.

Ваш ответ: Вы можете ссылаться на ServiceImpl напрямую, он будет служить цели, разница только в том, что ServiceImpl не является частью текущего модуля или какой-либо зависимости, но окончательный связанный проект будет реализован через некоторый родственный модуль, вероятно.

Ответ 3

Когда вы используете аннотацию @Autowired, Spring автоматически выполнит поиск в своем контексте приложения кандидата, который будет введен в контроллер. Действительный кандидат должен быть конкретным классом, помеченным как Spring bean, используя аннотацию @Service, например.

Ответ 4

@Controller - Контроллер - это точка входа, в которой вы потребляете запрос, поступающий из пользовательского интерфейса, определяете кучу сервисов и выкидываете путь URI сопоставления запросов, который сообщает, какой запрос поступает в бэкэнд, что возвращать. Затем вы создаете кучу сервисов, в которых вы пишете кучу интерфейсов, а затем вы можете продолжить и создавать кучу файлов ServiceImplementation, а затем DAO. Примечание по Autowired: он автоматически возвращает экземпляр, который вы указали в @Service - Особый класс должен рассматриваться как сервис, используемый для записи транзакций DAO. @Autowired приносит "экземпляр", который вам нужен откуда-то, обычно мы пытаемся найти "сервисы", которые вы хотите, из аннотации Autowired, затем вы можете добавить @qualifier, чтобы избежать путаницы в том, какой конкретный экземпляр вывести из похожих бинов.