Может ли Service иметь репозитории других классов?

Question

[Valeriy_Morozov]

Допустим у меня есть Entity A и Entity B. Могу ли я прямо обратиться к репозиторию Entity A из Service B? Или мне надо это делать вот так Service B -> Service A -> Repository A?

Проблема в том, что у меня все сервисы DTOшки, а для работы Service B нужны нормальные объекты, что делать в таком случае? Неужели создавать отдельные точно такие же методы просто без конверта в дто?

Answer 1

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

Могу ли я прямо обратиться к репозиторию Entity A из Service B?

Да, можно. Другой вопрос - хорошо ли.

Или мне надо это делать вот так Service B -> Service A -> Repository A?

Я предпочитаю этот способ.
Причина следующая:
Вот, представьте, что на сервисном уровне вы получаете Optional<T> из репозитория и в случае, если объект не найден, то на сервисном уровне выбрасываете исключение orElseThrow(). Ну а далее ExceptionHandler ловит исключение и отдает соответствующий код ошибки и сообщение на фронт.
Если вы решите из сервиса А обратиться в репозиторий Б, то по факту вам нужно заново получить объект и выбросить исключение в случае, если он не найден, а это уже дублирование кода...
Псевдокод:

ServiceA {
@Autowired
RepoB repoB;
@Autowired
ServiceB serviceB;

// 1 вариант
List<Job> doSomeJob1(String email){
User user =  repoB.findUserByEmail(email).orElseThrow(UserNotFoundException::new);
return user.getJobs();
}

// 2 вариант
List<Job> doSomeJob2(String email) {
User user = serviceB.getUserByEmail(email);
return user.getJobs();
}

RepoB {
Optional<User> findUserByEmail(String email);
}

ServiceB {
@Autowired
RepoB repoB;

User getUserByEmail(String email){
return repoB.findUserByEmail(email).orElseThrow(UserNotFoundException::new);
}

}

Во втором варианте нам не пришлось писать логику и выбрасывать исключение.
А так многое зависит от проекта, от того, как принято в команде работать и т.д.

Проблема в том, что у меня все сервисы DTOшки, а для работы Service B нужны нормальные объекты, что делать в таком случае? Неужели создавать отдельные точно такие же методы просто без конверта в дто?

Я это обычно, делаю по другому. Я возвращаю объекты из сервисов. А если мне нужно DTO, то есть отдельный сервис MapperService, который принимимает дженерик и возвращает соответствующие DTO.

Comments

[Valeriy_Morozov]

Вот проблема

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

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

Valeriy_Morozov,
Добрый день.
Насчет маппера - можно подключить библиотеку ModelMapper

<dependency>
            <groupId>org.modelmapper.extensions</groupId>
            <artifactId>modelmapper-spring</artifactId>
            <version>3.0.0</version>
        </dependency>

Затем создать интерфейс и его реализацию:

public interface MapperService {

    /**
     * Note: outClass object must have default constructor with no arguments
     *
     * @param <D> type of result object.
     * @param <T> type of source object to map from.
     * @param entity entity that needs to be mapped.
     * @param outClass class of result object.
     * @return new object of <code>outClass</code> type.
     */
    <D, T> D map(T entity, Class<D> outClass);

    /**
     * Note: outClass object must have default constructor with no arguments
     *
     * @param entityList list of entities that needs to be mapped
     * @param outCLass class of result list element
     * @param <D> type of objects in result list
     * @param <T> type of entity in <code>entityList</code>
     * @return list of mapped object with <code><D></code> type.
     */
    <D, T> List<D> mapAll(Collection<T> entityList, Class<D> outCLass);

    /**
     * Maps {@code source} to {@code destination}.
     *
     * @param source object to map from
     * @param destination object to map to
     */
    <S, D> D map(S source, D destination);

}

Имплементация:

@Service
@RequiredArgsConstructor
public class MapperServiceImpl implements MapperService {

    private final ModelMapper modelMapper;

    @Override
    public <D, T> D map(final T entity, Class<D> outClass) {
        return modelMapper.map(entity, outClass);
    }

    @Override
    public <D, T> List<D> mapAll(final Collection<T> entityList, Class<D> outCLass) {
        return entityList.stream().map(entity -> map(entity, outCLass)).collect(Collectors.toList());
    }

    @Override
    public <S, D> D map(final S source, D destination) {
        modelMapper.map(source, destination);
        return destination;
    }
}

Теперь, если понадобится замаппить любой объект, то достаточно:

Order order = mapperService.map(orderCreationRequest, Order.class);

или наоборот:

OrderCreationResponse orderCreationResponse = mapperService.map(order, OrderCreationResponse.class);

Теперь, дальше...
У вас есть и UserRepository и UserService. Можно удалить UserRepository и оставить только UserService. Вместо OrderMapper автовайрить MapperService. DishRepository также заменить на DishService. В общем, идея такова, что все репозитории, кроме репозитория соответствующей сервису сущности заменить на {Foo}Service. Оставить из репозитория только OrderRepository.

Но в принципе, это не ошибка. Т.е. можно и так оставить. Вопрос в том, как принято в команде работать.

[Valeriy_Morozov]

Орхан Гасанлы, огромное спасибо, а сам вызов конвертации происходит в контроллере?

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

Valeriy_Morozov, можно на сервисном слое, можно в контроллере. Я предпочитаю вызывать на сервисном слое.

Answer 2

[Михаил]

Технически вам никто не мешает так делать

Архитектурно - нужно смотреть по конкретному проекту.

Comments

[Valeriy_Morozov]

У меня тестовое задание, времени осталось совсем ничего. А сервис имеет столько зависимостей

Насколько это плохо?