Modèles de classes en Java et TypeScript

**dj_mez** · 20/02/2023, 13h59

Bonjour,

Dans ma montée en compétences, j'ai donc créé une petite appli toute simple que se soit côté backend (spring boot) et frontend (angular).

J'ai créé 2 classes en Java : Client et Commande avec une relation OneToMany pour Client et ManyToOne pour Commande.

Donc, dans Client.java j'ai :

@OneToMany
private List<Commande> commandes;

Et dans Commande.java j'ai :

@ManyToOne
private Client client;

Est-ce que je dois créer exactement le même modèle sous Angular (TS) ? Un tableau de commande dans client.ts et un object Client dans commande.ts ? Comment retranscrire ces relations dans Angular ?

Merci d'avance

**PhilippeGibault** · 20/02/2023, 15h23

La réponse est non, mais les arguments durs à exposer.

Pour commencer, on va commencer par la couche basse.

La couche basse, que l'on va appeler "entity" est manipulée par les DAO ( https://www.baeldung.com/java-dao-pattern ).

C'est en général, JPA/Hibernate qui est utilisé, mais on peut utiliser autre chose qu'une BDD Relationnelle (MongoDB,...), voir un autre framework (Spring JDBC...).

Partons des tables. Tu as une table commande qui a une clé étrangère sur la table client.

Ton Mapping est donc correct, mais il est incomplet.

Cette partie étant critique, je recommande d'être psychorigide et vieux con, comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
@Entity
@Table(name="COMMANDE")
public class Commande{
 //ID et Attribut
 
 @ManyToOne(fetch = FetchType.LAZY)
 @JoinColumn(name="CLIENT_ID", nullable=false)
 private Client client;
 
 //Getter Setter
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
@Entity
@Table(name="CLIENT")
public class Client{
 //ID Attribut
 
 @ManyToOne(fetch = FetchType.LAZY,mappedBy = "client")
 
 //Getter Setter
}

Là, on a mappé au mieux la BDD. A noté que j'ai ajouté la notion de LAZY/EAGER qui est fondamentale.
EAGER: Quand tu sélectionne la classe, Hibernate va aussi récupérer la classe lié (ce qui a partir d'un moment, revient à faire des requêtes en plus).

LAZY: On signale le lien mais Hibernate ne va pas chercher les données.

Couche suivante: DTO et Service.
Le lien est sympa, mais au fond, pour le service REST Spring, on n'a pas forcement besoin de toutes les informations.
Admettons que l'on cherche les commandes d'un client connu, là, on va vraiment couper, car en gros, la requête JPQL sera

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT commande FROM Commande commande WHERE commande.client.id = :idClient

Du coup, je n'ai pas besoin de passer à l'extérieur le client lorsque je lui passe la liste des commande.

Mieux, je ne passe peut-être que quelques données de la commande (numéro, date...) et pas le détail.
Donc la DTO devient:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class CommandeDTO{
 private String numeroComande;
 private String date;//Un string ici, sans doute une Date en BDD
 //Autre truc que je veux communiquer à l'extérieur
 
 //Le client, j'en ai rien à faire ici
 
 //Des Getter et des Setteur 
}

Cette façon peut aussi te sauver la vie car si tu construit des JSON, tu peux avoir des problème (concrètement des boucles de l'entité).

Ici, tu as les classes mappant la BDD et celles qui serves à communiquer vers l'extérieur. A toi de mapper dans un sens ou l'autre.

**PhilippeGibault** · 20/02/2023, 15h26

De fait, j'ai oublié de dire que dans Angular, en général, c'est ton modèle DTO, et non Entity. Évidement, tu peux couper également de la DTO vers le modèle angular.

**OButterlin** · 21/02/2023, 08h32

Envoyé par PhilippeGibault

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
@Entity
@Table(name="CLIENT")
public class Client{
 //ID Attribut
 
 @ManyToOne(fetch = FetchType.LAZY,mappedBy = "client")
 
 //Getter Setter
}

"Petite" erreur, c'est une annotation OneToMany de ce côté.

**dj_mez** · 21/02/2023, 13h18

Envoyé par OButterlin

"Petite" erreur, c'est une annotation OneToMany de ce côté.

Exact, c'est ce que j'ai mis @OneToMany

**dj_mez** · 21/02/2023, 13h32

Envoyé par PhilippeGibault

De fait, j'ai oublié de dire que dans Angular, en général, c'est ton modèle DTO, et non Entity. Évidement, tu peux couper également de la DTO vers le modèle angular.

Pour une entité, j'ai créé un Repo qui étend JPARepository, un service et un contrôleur.

Mon soucis c'était que lorsque je créais un client, pas de soucis.
Dès que j'ajoutais une commande, c'était la catastrophe... ça plantait et quand j'allais voir l'url de l'api, ça avait inscrit plusieurs fois la commande et plusieurs fois dans le tableau de client aussi..la donnée était à chaque fois imbriqué dans le tableau... à l'infini on dirait jusqu'à plantage

Je ne sais pas pour quelle raison ça fonctionne mais j'ai ajouté l'annotation @JsonIgnore à la relation OneToMany et ça a l'air de fonctionner mais je ne sais pas si ça l'enregistre en base... Je ne sais pas comment vérifier que ma relation existe. J'utilise MySQL via le PHPMyAdmin sous Ubuntu

@JsonIgnore
@OneToMany(targetEntity = Commande.class, mappedBy = "client")
private List<Commande> commandes;

De plus, je ne vois pas comment récupérer les commandes d'un client si je met cette annotation @JsonIgnore

**dj_mez** · 21/02/2023, 13h39

Envoyé par PhilippeGibault

La réponse est non, mais les arguments durs à exposer.

Pour commencer, on va commencer par la couche basse.

La couche basse, que l'on va appeler "entity" est manipulée par les DAO ( https://www.baeldung.com/java-dao-pattern ).

C'est en général, JPA/Hibernate qui est utilisé, mais on peut utiliser autre chose qu'une BDD Relationnelle (MongoDB,...), voir un autre framework (Spring JDBC...).

Partons des tables. Tu as une table commande qui a une clé étrangère sur la table client.

Ton Mapping est donc correct, mais il est incomplet.

Cette partie étant critique, je recommande d'être psychorigide et vieux con, comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
@Entity
@Table(name="COMMANDE")
public class Commande{
 //ID et Attribut
 
 @ManyToOne(fetch = FetchType.LAZY)
 @JoinColumn(name="CLIENT_ID", nullable=false)
 private Client client;
 
 //Getter Setter
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
@Entity
@Table(name="CLIENT")
public class Client{
 //ID Attribut
 
 @ManyToOne(fetch = FetchType.LAZY,mappedBy = "client")
 
 //Getter Setter
}

Là, on a mappé au mieux la BDD. A noté que j'ai ajouté la notion de LAZY/EAGER qui est fondamentale.
EAGER: Quand tu sélectionne la classe, Hibernate va aussi récupérer la classe lié (ce qui a partir d'un moment, revient à faire des requêtes en plus).

LAZY: On signale le lien mais Hibernate ne va pas chercher les données.

Couche suivante: DTO et Service.
Le lien est sympa, mais au fond, pour le service REST Spring, on n'a pas forcement besoin de toutes les informations.
Admettons que l'on cherche les commandes d'un client connu, là, on va vraiment couper, car en gros, la requête JPQL sera

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT commande FROM Commande commande WHERE commande.client.id = :idClient

Du coup, je n'ai pas besoin de passer à l'extérieur le client lorsque je lui passe la liste des commande.

Mieux, je ne passe peut-être que quelques données de la commande (numéro, date...) et pas le détail.
Donc la DTO devient:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class CommandeDTO{
 private String numeroComande;
 private String date;//Un string ici, sans doute une Date en BDD
 //Autre truc que je veux communiquer à l'extérieur
 
 //Le client, j'en ai rien à faire ici
 
 //Des Getter et des Setteur 
}

Cette façon peut aussi te sauver la vie car si tu construit des JSON, tu peux avoir des problème (concrètement des boucles de l'entité).

Ici, tu as les classes mappant la BDD et celles qui serves à communiquer vers l'extérieur. A toi de mapper dans un sens ou l'autre.

Si je comprends bien, tu ne passes pas par le repo, service, controleur comme j'ai fait ?

La requete JPQL, je l'écrit où ?

**PhilippeGibault** · 21/02/2023, 13h42

Non.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
public class ClientDTO{
 
 private List<CommandeDTO> commandes;
 
 //ect 
}

La DTO étant ce qui va être transféré.

Un détail:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
@OneToMany(targetEntity = Commande.class, mappedBy = "client")
private Set<Commande> commandes;

Le Set est préféré à la List, car chaque commande est sensé être unique.

Après, à toi de faire le mapping entre les DTO et les Entités.

**PhilippeGibault** · 21/02/2023, 13h57

Je peux te donner le lien de mon projet perso pour l'exemple:
https://bitbucket.org/philippegibaul...r40k/src/main/

Pour commencer, @JsonIgnore n'est pas la solution mais le problème. C'est même une mauvaise pratique.

En gros, tu as deux classes, Commande et Client qui sont liées et tu transforme en JSON des données qui sont dans des POJO.
Tu cherches à avoir la commande et son client.

L'ensemble prend la commande, JSON, pas de problème.

Puis, il prend le client lié à la commande, JSON, pas de problème.

Puis il prend les commandes (toutes!!!!!!!) pour JSON.

Puis il prend les clients de chaque commande (qui en plus est le même) et JSON.

Puis pour chaque client (qui est le même) il prend encore les commandes puis re-JSON.

Bref -> Boucle infini.

Le @JsonIgnore sert à justement stopper ce processus infernal!

Mais la bonne pratique est de différentier ce que l'on transfert vers l'extérieur (la DTO pour Data Transfert Object) de l'entité.

En fait, tu découpe en couche. et en rôles. Mapper la BDD n'a rien à voir avec transférer les informations vers l'extérieur. C'est deux rôles différents.

La couche la plus basse
Les POJO sont les entités. Là, tu mappe avec la BDD via JPA (et ses annotations diverses et variées).

Ce qui manipule les Entités sont les DAO. Ce sont en général des CRUD (https://fr.wikipedia.org/wiki/CRUD ).
C'est dans les DAO que tu écris les requête en BDD.

Couche service
Ici, tu va injecter des DAO. Et des classe de mapping pour passer de la DTO vers l'entité ou inversement.
Tu peux implémenté des règles métiers ici, même si aujourd'hui, on a changé d'approche (Architecture hexagonale).
Le service retourne les DTO.

Couche Rest
Tu injecte les services ici.

**PhilippeGibault** · 21/02/2023, 14h00

J'ai effectivement oublié Angular. Angular va appeler la couche REST et récupérer la DTO sous forme JSON.

De fait, l'interface Angular est une copie (totale ou partielle) de ta DTO.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
export interface Commande{
 client: Client[];
 //ect ...
}

Et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
export interface Client{
 //ect...
}

**PhilippeGibault** · 21/02/2023, 14h03

Spring a tellement mâché le travail qu'effectivement, on a un peu changé de langage.

La DAO, c'est la même chose que le repository (@Repository) et c'est le CRUD Spring.

**PhilippeGibault** · 21/02/2023, 14h04

Et le service, chez Spring, c'est @Service.

**dj_mez** · 21/02/2023, 14h07

Envoyé par PhilippeGibault

Spring a tellement mâché le travail qu'effectivement, on a un peu changé de langage.

La DAO, c'est la même chose que le repository (@Repository) et c'est le CRUD Spring.

La DAO ce ne serait pas plutot le controleur ?

**dj_mez** · 21/02/2023, 14h10

Oui, Spring a mâché le travail et j'aimerais bien savoir le faire manuellement, sans passer par Spring, au moins pour savoir ce qui se cache réellement derrière Spring.

Je trouve que c'est bien de savoir le faire manuellement.

Mais comme je n'ai pas encore d'expérience, c'est plus rapide d'apprendre et de comprendre via un framework. Une fois qu'on y arrive, qu'on peut créer un CRUD avec plusieurs entités avec des relations entre eux, je pense qu'on peut se pencher sur l'envers du décor de Spring pour creuser un peu plus la logique

**PhilippeGibault** · 21/02/2023, 14h15

La DTO et l'Entité, ça n'a rien à voir.

L'entité est ce qui sert à mapper la BDD. C'est ce qui permet de manipuler la BDD.

La DTO, c'est ce qui (après avoir été JSON) va être transmis vers l'extérieur.

En fait, en ayant les terminologies (et en partant du principe que si on demande une commande, on a le client),

On a côté entité:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
@Entity
@Table(name="CLIENT")
public class ClientEntity{
 
 //ect...
 @OneToMany(fetch = FetchType.LAZY,mappedBy = "client")
 private Set<CommandeEntity> commandes
 //ect...
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
@Entity
@Table(name="COMMANDE")
public class CommandeEntity{
 
 @OneToMany(fetch = FetchType.LAZY)
 @JoinColumn(name="CLIENT_ID", nullable=false)
 private Client client;
}

Et comme je coupe, j'ai en DTO pour la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public class CommandeDTO commande{
 //ect...
}

La DTO n'a pas le même rôle que l'entité.

**PhilippeGibault** · 21/02/2023, 14h18

Envoyé par dj_mez

Oui, Spring a mâché le travail et j'aimerais bien savoir le faire manuellement, sans passer par Spring, au moins pour savoir ce qui se cache réellement derrière Spring.

Je trouve que c'est bien de savoir le faire manuellement.

Mais comme je n'ai pas encore d'expérience, c'est plus rapide d'apprendre et de comprendre via un framework. Une fois qu'on y arrive, qu'on peut créer un CRUD avec plusieurs entités avec des relations entre eux, je pense qu'on peut se pencher sur l'envers du décor de Spring pour creuser un peu plus la logique

Je suis entièrement d'accord et je t'y encourage. Tu trouveras des exemple dans mon projet perso, où je suis reparti de zéro et où j'ai ajouté spring que lorsque c'était nécessaire (projet dao, entity, service,dto et rest)

**PhilippeGibault** · 21/02/2023, 14h19

Envoyé par dj_mez

La DAO ce ne serait pas plutot le controleur ?

@RestController

**dj_mez** · 21/02/2023, 14h21

Envoyé par PhilippeGibault

La DTO et l'Entité, ça n'a rien à voir.

L'entité est ce qui sert à mapper la BDD. C'est ce qui permet de manipuler la BDD.

La DTO, c'est ce qui (après avoir été JSON) va être transmis vers l'extérieur.

En fait, en ayant les terminologies (et en partant du principe que si on demande une commande, on a le client),

On a côté entité:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
@Entity
@Table(name="CLIENT")
public class ClientEntity{
 
 //ect...
 @OneToMany(fetch = FetchType.LAZY,mappedBy = "client")
 private Set<CommandeEntity> commandes
 //ect...
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
@Entity
@Table(name="COMMANDE")
public class CommandeEntity{
 
 @OneToMany(fetch = FetchType.LAZY)
 @JoinColumn(name="CLIENT_ID", nullable=false)
 private Client client;
}

Et comme je coupe, j'ai en DTO pour la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public class CommandeDTO commande{
 //ect...
}

La DTO n'a pas le même rôle que l'entité.

D'accord. C'est une couche au dessus de celle de l'entité.. Je vois.
Et la DAO c'est une autre couche qui fait l'interface avec la BDD comme le repo.

As-tu une bonne ressource sur les différentes couches ? Vidéo si possible, merci.

je vais jeter un oeil à ton app pour voir. Merci

**PhilippeGibault** · 21/02/2023, 14h39

**dj_mez** · 21/02/2023, 15h16

Envoyé par PhilippeGibault

Merci ! Je connais ces cours. Ils sont très bons. Par contre, pour s'y retrouver dans ses playlists, ce n'est pas évident. Je lui avais demandé un ordre de visionnage mais aucune réponse.

Je vais donc jeter un oeil à celle que tu me conseilles car je ne l'ai pas visionné. Je l'ai croisé mais pas visionné. Encore merci.

Ce que tu me proposes avec le DTO, ce n'est pas de faire du JEE pur mais une couche en plus en utilisant Spring ?

J'avais vu justement une vidéo de ce professeur qui montrait un projet sans utiliser Spring puis en utilisant Spring et la différence était assez folle ! J'ai aimé son approche, celle de savoir faire les 2 mais je ne pense pas qu'il a combiné les 2 dans la vidéo. Peut etre dans d'autres.

Juste avant celle-là, j'avais vu une série sur l'architecture JEE..

Modèles de classes en Java et TypeScript

Spring Web Java

Discussions similaires

Partager

Partager