Entities et son utilisation

[Djiouvi]

https://github.com/bGrisafi/mesRecettes_back/blob/8ec4af1d399af6b38420d937d166479bfcbf95b3/src/main/java/Br/mesRecettes/entities/Recettes.java#L15

Alors Je fais un pavé ici pcq flemme de faire 45 tickets.

0) entity = représentation de la DB

1) nomification : petit conseil, nomme tes entities : UserEntity, PaysEntity etc. Car comme ça ton DTO s'appelera User, Pays. ça sera BEAUCOUP moins chiant.

2) il te manque tes DTOs à chaque fois que tu travailles, ça sera à travers les DTOs. Alors oui, tu pourrais tout faire via entity mais ce n'est pas ce que fait Spring. Techniquement tu n'es jamais sensé travailler sur les Entities. Alors oui, tu le feras pcq des fois t'as pas le choix. Mais ici, termine de faire une bonne découpe. On ne retourne jamais une entity côté front car tu exposes ton objet DB au "monde". Même si le DTO ressemble à 99% à l'entité.

3) Pro tips : tu peux ajouter de l'audit : create_at, update_at, create_by(si t'es chaud) et update_by

4) pour générer un script SQL et qui se fait executer. Voir liquibase. Si tu comprends liquibase, tu comprendras tous les ORM. Il est pas compliqué, faut un peu chipoter mais il en vaut la peine. Je suis un grand fan. On utilise ça chez NSI. Très efficace

[bGrisafi]

OK, a part le point 2 tout est clair

pour les DTO, j'ai encore un peu de mal avec, c'est pas ce que fait déjà le Repository ? L'entity est utilisée par le Repo pour interagir avec la DB, ensuite c'est fourni à un service (que j'ai pas encore implémenté, pour l'instant comme tu l'as vu ca se fait dans le controller ce qui est pas OK), service utilisé par le controller, qui lui-même fourni les endpoints de l'API au client

Ou viennent les DTO dans cette structure du coup ? Faut supprimer le repo et remplacer ca par des DTO ou venir servir d'interface entre l'entity et le repo ?

[Djiouvi]

Là est la complexité justement. Rien ne t'empeche de travailler avec ton entity comme objet "courant". Mais c'est pas propre. Son but c'est uniquement d'être la structure entity de ta DB.

Le but de ton DTO, c'est d'avoir un objet sur lequel tu peux travailler dessus, faire tes manipulations etc. Petite exemple : `@Entity @Table(name = "licence") @Getter @Setter @Documentation("Licence d'un chasseur invité") public class LicenceEntity extends AbstractBaseAuditableEntity { @ManyToOne(fetch = FetchType.LAZY, optional = false) private DemandeEntity demande;

@ManyToOne(fetch = FetchType.LAZY, optional = false)
private ChasseurEntity chasseurInvite;

@OneToMany(mappedBy = PeriodeEntity_.LICENCE, cascade = CascadeType.REMOVE)
@OrderBy("dateDebut asc")
private List<PeriodeEntity> periodes;

} Et son DTO @Getter @Setter public class Licence extends AbstractBase { private Long demandeId; private Long chasseurInviteId; private List periodes; }`

Quand tu as cette structure : controller - service - repo Avec les objets dto - entity il te manque un mapper mapstruct (dinguerie mais complexe à mettre en place) ou alors si la flemme. Tu le fais à la main. Mais par contre, si ça t'emmerde pcq ça reste avancer comme système. Alors travaille avec l'entity. Mais c'est pas propre pcq ce n'est que ton model DB