Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Encapsular na criacao do objeto DTO a busca pela Entidade JPA

Boa tarde, o curso está muito maneiro rs. Estou com 2 pontos de reflexão

Seguindo o exemplo da aula, temos no controller algo como:

public List<TopicoDto> lista(String nomeCurso) {
    if (nomeCurso == null) {
        List<Topico> topicos = topicoRepository.findAll();
        return TopicoDto.converter(topicos);
    }
}

1 - Se eu fizer assim.. é bom ou ruim?

public List<TopicoDto> lista(String nomeCurso) {
    if (nomeCurso == null) {
        return TopicoDto.converter(topicoRepository);
    }
}

public static List<TopicoDto> converter(TopicoRepository topicoRepository) {
        List<Topico> topicos = topicoRepository.findAll();
        return topicos.stream().map(TopicoDTO::new).collect(Collectors.toList());        
    }

2 - Eu poderia ao invés de usar o método static converter, usar o construtor da classe DTO? E no corpo do construtor, fazer a busca da entidade no banco e depois "converter" para o DTO?

Agradeço desde já.

2 respostas
solução!

Oi Rodrigo,

É uma opção válida também, e embora esse esquema de utilizar o repository no dto seja mais simples, acredito não ser tão comum de fazerem desse jeito no mercado :D

O mais comum é isolar esse tipo de código em classes services, para que nem o DTO e nem o Controller contenham lógicas.

Como o foco do curso é o Spring Boot e não boas práticas de programação, fiz desse jeito por ser mais simples e fácil e com isso não tirar o foco do curso.

Bons estudos!

Professor, obrigado pelo retorno. Nesse caso, como não foi exigido nenhuma validação de negócio para obter o resultado do banco, achei tranquilo fazer assim. Pois se não fizesse assim, a classe de serviço serviria apenas para delegar para o repository. Em casos em que precisa fazer alguma validação de negócio, entendo que devo utilizar uma classe de serviços. Obrigado.