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

Tendo em vista o problema do detached, em que situação ter um setID seria justificável?

Quando a gente cria um objeto novo, o id é criado automaticamente. Se precisamos buscar os dados de um objeto do banco, usamos o find que já popula este campo automaticamente.

Assim sendo, existe algum cenário no qual um setID seria justificável existir?

Curiosamente criei algo semelhante ao que estou vendo neste curso no sistema VB6 da empresa onde trabalho para que os programadores não tenham que ficar programando SQL a toda hora ao manipular dados dos objetos no banco e me deparei com esta situação. Achei que deveria remover os Lets (equivalente a set) de ID nas classes como medida de segurança, de modo que o programador faria o equivalente ao find do JPA e faria set só do que precisasse mudar, ou na criação de um novo objeto, popular todos os campos e o banco de dados se viraria com a criação do ID (que é populado no objeto pelo meu método de insersão no banco).

Obrigado

4 respostas

Em ambiente de testes. Você pode querer criar uma instância de uma entidade na mão para usar em algum cenário. Tudo isso rodando seu código fora de um container.

Blz? Se tiver tudo certinho não esqueça de marcar como solucionado.

solução!

No geral a JPA utiliza o setId quando o objeto é carregado. Ao usar o find or exemplo, a Id é inserida no objeto.

Bernardo, então se eu não programar o setID, o JPA não vai conseguir preencher o ID? Interessante... Faz sentido.

Obrigado!

Edit: Flávio, desculpa-me a demora em responder e marcar como solucionado. Não tenho tido muito tempo pro Alura ultimamente.