Как в Spring правильно создавать и инжектить сервисы?

Question

[Степан]

Разбираюсь со Спрингом, и некоторые вещи мне не до конца ясны. К примеру, прочитанная недавно статья: https://habr.com/ru/post/352954/
В тексте приводится пример создания сервисов:
1. Создаётся интерфейс EmailService:

public interface EmailService {
    void send(String to, String title, String body);
}

2. Реализуя его, создаётся сервис, в котором переопределяется метод:

@Service
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class EmailServiceImpl implements EmailService {

    private final JavaMailSender emailSender;

    @Override
    public void send(String to, String subject, String text) {
        MimeMessage message = this.emailSender.createMimeMessage();
        MimeMessageHelper helper = new MimeMessageHelper(message);
        try {
            helper.setTo(to);
            helper.setSubject(subject);
            helper.setText(text);
            this.emailSender.send(message);
        } catch (MessagingException messageException) {
            throw new RuntimeException(messageException);
        }
    }
}

А дальше в SchedulerService инжектится не EmailServiceImpl, а "исходный" EmailService:

@Slf4j
@Service
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class SchedulerService {

    private final UserRepositoryService userService; 

    private final EmailService emailService;

}

Вопросы, которые мне не ясны:
1. Это нормально?
2. Почему инжектится "исходный" интерфейс?
3. Зачем создаётся EmailServiceImpl, если он не используется? Он ведь не используется?
4. Тут какая-то хитрая магия Spring? Он видит, что есть ИмяИнтерфейсаImpl и учитывает это в процессе? Как это работает?
5. Как правильно в Spring создавать интерфейсы и правильно их инжектить?

Answer 1

[Dmitry Roo]

1. Да
2. Интерфейс не класс и не бин - его нельзя заинжектить. Там указано, что нужно заинжектить Бин, реализующий интерфейс.
3. EmailServiceImpl как раз и будет использоваться, т.к. он реализует требуемый интерфейс.
4. Назвать сервис можно как угодно. Главное, чтобы он реализовывал нужный интерфейс.
5. См. п2

Comments

[Степан]

3. EmailServiceImpl как раз и будет использоваться, т.к. он реализует требуемый интерфейс.

Где в приведённых мной кусках кода написано, что используется именно EmailServiceImpl?

В сервисе SchedulerService, как я вижу, инжектится EmailService, от которого наследуется EmailServiceImpl, который нигде не используется. Так ведь? Значит, в коде ошибка?

[Dmitry Roo]

Степан,

Где в приведённых мной кусках кода написано, что используется именно EmailServiceImpl?

нигде. Это называется "слабая связанность". В сервис SchedulerService внедряется любой бин, реализующий интерфейс EmailService. Не обязательно конкретно EmailServiceImpl, но EmailServiceImpl вполне подойдёт.

[Степан]

Dmitry Roo, спасибо, добрый человек, стало понятнее.

Answer 2

[Орхан Гасанлы]

1. Это нормально?

Да, нормально. Вообще, наличие сервисного слоя для реализации бизнес-логики необходимо. В сервисном слое вы можете валидировать dto, конвертировать dto <-> model, а также описывать любую бизнес-логику.

2. Почему инжектится "исходный" интерфейс?

Коллега подсказал вам правильно. Инжектится реализация данного интерфейса. Если у интерфейса есть несколько реализаций, то необходимо будет уточнить какая реализация должна быть заинжекчена

Зачем создаётся EmailServiceImpl, если он не используется? Он ведь не используется?

Конечно же используется. Во время работы происходит примерно следующее:

private EmailService emailService = new EmailServiceImpl();

Тут какая-то хитрая магия Spring? Он видит, что есть ИмяИнтерфейсаImpl и учитывает это в процессе? Как это работает?

Как я и сказал выше, если у интерфейса несколько реализаций, то необходимо уточнить название бина, который должен заинжекчен. Ну а если у интерфейса одна реализация, то конечно же она и будет автоматически взята.

Как правильно в Spring создавать интерфейсы и правильно их инжектить?

Собственно говоря, создайте нужный интерфейс. Затем имплементируйте данный интерфейс. В классах (контроллерах или еще где-то) используйте сам интерфейс для создания слабых связей.
А сприн сам "решит" какую реализацию подключать, ну или же укажите название бина, который нужно заинжектить.

Comments

[Степан]

Но ведь не будет ошибкой такой вариант:
1. Интерфейс:

public interface IFileService {
    void init();

    String save(MultipartFile file);

    Resource load(String filename);
}

2. Сервис:

@Service
public class FileService implements IFileService {

    @Override
    public void init() {
        try {
            Files.createDirectory(uploadsFolder);
        } catch (IOException e) {
            throw new RuntimeException("Не получилось создать папку " + uploadsFolder);
        }
    }

    @Override
    public String save(MultipartFile file) {
...

3. Контроллер:

public class AuthController {
    private static final Logger log = LoggerFactory.getLogger(AuthController.class);

    @Autowired
    private FileService fileService;
...

То есть когда я инжекчу конкретную реализацию (FileService), а не сам интерфейс (IFileService).

"Как я и сказал выше, если у интерфейса несколько реализаций, то необходимо уточнить название бина, который должен заинжекчен."

Могли бы привести пример кода? Спасибо.

[Орхан Гасанлы]

Степан,

Но ведь не будет ошибкой такой вариант:

Нет, это конечно же не ошибка. Другое дело, что в программировании есть различные принципы и паттерны, которых стараются придерживаться. В данном случае это GRASP
https://habr.com/ru/post/92570/
https://ru.wikipedia.org/wiki/GRASP

А также собственно говоря, https://habr.com/ru/post/131993/

Могли бы привести пример кода? Спасибо.

1) это аннотация Primary
https://www.baeldung.com/spring-primary
Если у вас несколько имплементаций интерфейса, но при этом над одним из классов стоит аннотация Primary, то этот класс будет приоритетнее.

@Component
@Primary
public class GeneralManager implements Manager {

2) Аннотация Qualifier

@Autowired
    @Qualifier("fooFormatter")
    private Formatter formatter;

https://www.baeldung.com/spring-qualifier-annotation
3) А также аннотации Resource & Inject
https://www.baeldung.com/spring-annotations-resour...

[Степан]

Орхан Гасанлы, спасибо, ознакомлюсь.

[Степан]

Орхан Гасанлы, если позволите, у меня дополнительный вопрос: как грамотно инжектить?
Например: в контроллер можно инжектить только сервисы, а в сервисы — репозитории и другие сервисы. Или в сервисы можно инжектить только другие сервисы? Или вообще без разницы (в том смысле, что ничего не сломается, но архитектурно это неправильно)?

[Орхан Гасанлы]

Степан,
Если ответить на ваш вопрос простыми словами, то в контроллер инжектите интерфейс (и создаете сервис, который имплементирует этот сервис). А в сервис уже инжектятся другие интерфейсы и сервисы, а также репозитории и конвертеры и прочее.

Или в сервисы можно инжектить только другие сервисы?

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

Сломаться может следующее (как вариант):
circular dependencies - https://www.baeldung.com/circular-dependencies-in-...

почти похожая ситуация может быть и на модульном уровне, когда у вас есть 2 модуля, которые зависят друг от друга и собрать подобный проект не предоставляется возможным.