Bien que probablement une question triviale, je me suis toujours demandé à ce sujet.
Habituellement, après l'insertion dans la DB, il semble une pratique courante de retourner l'ID de l'entité commerciale. P>
@Override
public Long createUser(UserEntity user) {
em.merge(user);
em.flush();
return user.getId();
}
4 Réponses :
Selon mon expérience, le processus d'insertion retourner l'ID à l'entité commerciale est une bonne pratique, car cet identifiant pourrait être utilisé en totalité pour poursuivre le processus métier tel qu'il est inscrit récemment, De plus, pour le processus de mise à jour, nous récupérons l'entité avant de mettre à jour l'enregistrement afin que nous ayons déjà reçu l'ID, il n'est donc pas nécessaire de renvoyer l'identifiant
Oui, mais en ce qui concerne l'insertion, le retour de l'objet Business Ref si l'ID est défini avant de revenir. D'accord pour la partie de mise à jour!
Je pense aussi que le retour de l'identifiant en général est bon, sinon même. Ou vous pouvez également retourner l'objet entier, mais c'est un peu "aérien" si vous n'avez plus besoin de travailler avec elle plus après la création.
Lors de la mise à jour / modification d'un objet dans la base de données, nous retournons toujours l'objet lui-même ou probablement juste un booléen à la mise à jour de la mise à jour et non depuis que nous avons déjà l'objet.
Pourquoi ne pas renvoyer l'instance entière s'il a été créé / mis à jour avec succès? La même chose que les données de printemps font, Qu'est-ce que je dois faire si j'ai besoin d'une autre partie de l'objet créé / mis à jour, sauf pourquoi Il n'y a aucune difficulté à renvoyer tout l'objet (rien n'est "frais de tête" comme mentionné par @danny Fonk), mais cela peut économiser beaucoup de temps à l'avenir.
ID ? ( nom , date pour un utilisateur ).
ID est-il de retour s'il existe quelques champs qui caractérisent exactement une instance (une clé primaire composite)?
Si vous retournez l'entité, le code client ressemblerait à ceci: mais "e" et "créé" sont le même objet. Cela peut conduire à la confusion. Vous pouvez faire valoir que vous pouvez modifier à l'avenir la mise en œuvre de votre méthode de création afin qu'elle renvoie vraiment une entité différente. J'ai vu ça. Je n'ai pas aimé ça. C'était imho une terrible design de persistance. Il y a maintenant une situation où je pense que le retour de l'identifiant est une bonne option: si vous avez une limite de transaction (requis_new) autour de votre méthode de création. Passage des identifiants au lieu d'entités par des limites de transaction n'est pas une mauvaise chose.
Je ne sais pas pourquoi ce serait le cas. Vous pouvez simplement faire référence à l'entité retournée à l'original ... Maintenant, j'y pense, je suppose que vous pouvez même retourner vide (bien que cela ne soit pas très explicite), car ce qui est passé est une copie de la référence et juste Définissez l'identifiant dans le DAO.
La fusion laisse l'entité transmise détachée, copie son état d'une entité gérée et retourne l'entité gérée. Le retour de l'identifiant est inutile: l'appelant le sait déjà car il l'a adoptée dans l'entité. Ce que l'appelant a besoin est l'entité gérée créée ou mise à jour.
@Jbnizet merci cela a du sens.
Oui, l'accent est mis sur le fait que la commande de fusion retourne l'objet d'entité fusionné. À mon avis, c'est la meilleure pratique. Il suffit de retourner l'objet userentity renvoyé par la commande FusionGE. La raison en est que c'est généralement une bonne pratique de ne pas modifier un objet passé comme paramètre. Donc, vous devriez probablement s'attendre à ce que la méthode de fusion ne modifie pas l'objet transmis. Et retournez toujours le même objet (ou une partie de celui-ci), qui a été transmis à votre méthode peut ne pas être aussi utile.