Ao implementar a exclusão, a instrutora buscou o registro pelo id e depois fez um .flatMap chamando o método de exclusão. Há algum benefício nisso ao invés de chamar direto o deleteAllById?
Ao implementar a exclusão, a instrutora buscou o registro pelo id e depois fez um .flatMap chamando o método de exclusão. Há algum benefício nisso ao invés de chamar direto o deleteAllById?
Oi Bruno! Tudo bem?
A escolha de buscar o registro pelo ID antes de fazer a exclusão pode ter algumas justificativas, especialmente em um contexto reativo como o do WebFlux. Vamos explorar algumas razões para isso:
Verificação de Existência: Ao buscar o registro antes de excluí-lo, você garante que o registro realmente existe antes de tentar deletá-lo. Isso pode ser útil para evitar exceções ou erros inesperados ao tentar excluir um registro inexistente.
Fluxo Reativo: Usar flatMap
após findById
permite que você continue a trabalhar dentro do fluxo reativo. Isso pode ser importante para manter a aplicação não bloqueante e reativa, aproveitando ao máximo as capacidades do WebFlux.
Operações Condicionais: Buscar o registro primeiro pode permitir que você realize operações condicionais antes de decidir excluir. Por exemplo, você pode querer verificar se o registro atende a certas condições antes de excluí-lo.
Tratamento de Erros: Ao buscar o registro antes, você pode tratar erros de maneira mais granular. Por exemplo, se o registro não for encontrado, você pode retornar uma mensagem de erro específica ao usuário.
Embora o método deleteAllById
possa parecer mais direto, ele pode não oferecer o mesmo nível de controle sobre o fluxo e o tratamento de erros que a abordagem mencionada pela instrutora.
Espero ter ajudado e bons estudos!
Interessante, realmente são boas justificativas.
Obrigado pela resposta!