Page 1 sur 1

questions de cours

Publié : 19 janv. 2020 23:31
par velitc_v
Bonjour,
Voici pour info des questions de cours échangées avec M. Rosmorduc
______________________________
Je précise d'abord que - sauf indication contraire dans cette réponse, la plupart des questions
qui suivent débordent largement de ce qui est demandé à l'examen.

JPA AVANCÉ

pour @Inheritance(strategy=InheritanceType.JOINED) et TABLE_PER_CLASS on ne se sert pas de DTYPE
car il n'y a pas de champs commun DTYPE créé. Donc on pourrait l'omettre, ou est ce que l'annotation a un autre rôle ?
@DiscriminatorColumn(name="DTYPE") et @DiscriminatorValue("txt")
Pour TABLE_PER_CLASS, le @DiscriminatorColumn ne sert à rien - il faudrait que je le supprime de mon cours
pour InheritanceType.JOINED, ça dépend des implémentations de JPA. Certaines en ont (ou en avaient) besoin. A priori, ça reste une bonne idée de
l'utiliser :
Si je fais un "select d from Document d where d.id = 3", la présence d'un @DiscriminatorColumn facilite potentiellement
le travail de JPA pour retrouver l'objet complet - il sait dans quelle classe chercher.

Slide 31-32 JPA AVANCE

Il y a une erreur sur le slide et je ne suis pas sûr d'en comprendre le sens.
"Quand on les éléments/non entités sont dans une collection, on utilise @ElementCollection ;"
@ElementCollection n'est que pour les @Embedded ? ça veux dire qu'il y a une classe Labels avec l'annotation @embaddable ?
@Entity
public class Message {
@Id
private Long id;
@ElementCollection
Set<String> labels;
}
Il faudrait que je sois plus précis : @ElementCollection peut fonctionner avec :

des types "simples" : en général tous ceux qui correspondent à une seule colonne dans une table SQL : Integer, String, Date...
des types @Embeddable
Ici, on est dans le premier cas.

Pour les Map annotées par @ElementCollection, on a les
possibilités suivantes :

la clef et la valeur sont des types simples (primitifs, String, Date) ou @Embeddable
la clef est une entité, la valeur est un type simple ou @Embeddable.
Dans cette requête de la class SelectGlouton des exemples de cours JPA :
06_spring_jpa/03_jpa_glouton je ne comprends pas le e de cette requête, A quoi correspond t'il ?
select distinct c from Cours c left join fetch c.etudiants e
Il ne sert pas à chose.

Ce "e" sert à nommer l'objet Etudiant qui permet de parcourir la collection c.etudiants. Il permettrait par exemple d'écrire :

select distinct c from Cours c left join fetch c.etudiants e where e.nom = 'toto'
(requête qui récupère les cours suivis par un étudiant du nom de toto).

Comme ici, on n'est pas intéressé par les conditions sur e, mais qu'on veut simplement modifier la lecture des données,
ça n'est pas utile de nommer e. Je l'ai fait de manière un peu mécanique.

Slide 4 de JPA AVANCE
Si je peux me permettre, il faudrait préciser un exemple pour FetchType.EAGER pour savoir comment l'utiliser : annotation, attribut.. ?
@OneToOne(fetch=FetchType.EAGER) // la relation est chargée par défaut
Vous avez raison. C'est bien l'attribut fetch des annotations. Je vais ajouter un transparent à ce sujet...

REST

Slide 12-13
le slide 12 c'est la description du webservice ?
le slide 13 c'est l'interrogation du web service ? c'est quoi top/down ?
Non : la slide 12, c'est un récapitulatif des diverses parties du fichier WSDL. La slide 13 et les suivantes
décrivent chacune des parties.

"top/down" est assez mal choisi en l'occurrence... j'aurais plutôt dû dire bottom-up... et pour tout dire, "vision détaillée" aurait été mieux choisie.

Slide 18
Qu'est ce que l' UDDI ?
Un système d'annuaire qui permet d'enregistrer les services. Contrairement à JNDI, qui est spécifique à JEE, UDDI est portable
et basé lui-même sur des WEB Services.

Slide 21
de l'extérieur on voit l'implémentation et l'interface ou que l'interface ?
Uniquement l'interface.

Slide 48
Quelle est la différence entre @ResponseBody et @RequestBody. c'est pas clair, pourquoi as t'on besoin des deux.
Ce point est important à comprendre :

@ResponseBody
la méthode est une fonction, qui renvoie un résultat. Ce résultat est directement utilisé comme réponse.

Par défaut, en Spring MVC, la valeur de retour est une String qui donne le nom de la vue à afficher, ou un objet ModelAndView.

Avec @ResponseBody, c'est directement l'objet retourné qui est affiché, moyennant des transformations.

Par exemple, si le type de retour est String, et qu'on annote la méthode avec @ResponseBody, le texte affiché par le navigateur sera directement la String retourné.

Si POJO (un objet avec des accesseurs, etc) est retourné, il sera a priori sérialisé en JSON et récupéré ainsi par le client.

C'est l'utilisation qu'on fait de @ResponseBody en REST.

@RequestBody
quand on utilise AJAX, il est fréquent que les données expédiées ne proviennent pas d'un formulaire. Du coup, au lieu d'envoyer les données au serveur sous la forme classique champ1=valeur1&champ2=valeur2... on préfère souvent les envoyer sous la forme d'un objet JSON :

{"champ1": "valeur1", "champ2": "valeur2"}
@RequestBody marque un argument de la méthode du contrôleur en indiquant qu'il va être rempli à partir des données de la requête,
qui sont censées être sérialisées en JSON ou XML.

Slide 54

ParameterizedTypeRef : Comment est ce qu'en créant une classe abstraite ça nous retourne la même en private ? la cuisine de Spring ? utilisation de l'introspection, j'imagine..?
Non, c'est du java "standard". On a une classe abstraite, ParameterizedTypeReference. Le code

responseType = new ParameterizedTypeReference<ArrayList<Contact>>(){};
Crée une classe anonyme, ce qui utilise un mécanisme très classique en java (quoi que pas très lisible !!). Les Listener en Swing sont souvent implémentés de cette manière.

On peut aussi créer une classe "normale" si on veut - mais ça ne sert pas à grand chose :

Quelque part dans le code :

public class ReponseListeContact
extends ParameterizedTypeReference<ArrayList<Contact>>{
// rien !!!
}
Utilisation :

ResponseEntity<ArrayList<Contact>> res = restTemplate.exchange(
url, HttpMethod.GET, null, new ReponseListeContact());
Le problème que résoud ce code - comme expliqué dans les transparents - est que java "oublie" la valeur des arguments de types
génériques. Ils sont utilisés à la compilation, mais pas à l'exécution.

C'est dû en grande partie au désir de rester compatible avec Java 1.0, qui n'avait pas de génériques.

si j'utilise directement ParameterizedTypeReference<ArrayList<Contact>>, java oublie à l'exécution que les données JSON doivent être converties en ArrayList<Contact> (après, on passe effectivement par de l'introspection)
la classe ReponseListeContact (ou son équivalent anonyme) a pour seul but de "geler" dans le corps de la classe elle-même le type de l'argument ArrayList<Contact> afin qu'il soit connu à l'exécution. Ça n'est plus une classe générique, mais une classe java "normale".
Pour mieux le faire comprendre :

Si j'ai écrit :

List<String> l= new ArrayList<String>();
à l'exécution, je ne peux pas savoir quel type de données est censé être renvoyé par l.get(i). Parce que l est de classe ArrayList, qui est un type générique.

Si j'ai créé :

class ListString extends ArrayList<String> {};

...
ListString l = new ListString();
l est maintenant de type ListString, qui n'est pas générique.
La méthode l.get(i) renvoie une String.

Slide 58

HateOAS je ne comprends pas withSelfRel() et WithRel(). La doc indique que ça crée un lien. Y a t'il autre chose à savoir ? qu'est ce que Rel ? available est un mot clé ou juste une valeur que vous avez décidé ?
Le mieux est de regarder le transparent 62 pour voir la tête du résultat. L'objet JSON renvoyé contient les données "normales", plus des liens qui indiquent où on peut ensuite naviguer.

withSelfRel
ajoute un lien "self" qui redonne l'URL associée à l'objet affiché ;
withRel
ajoute un autre lien, dont on donne le nom ;
available est simplement un nom qu'on a donné au lien. Il est parfaitement arbitraire.

C'est une aide à la lisibilité du code, et il est utilisé en JSON comme clef dans le tableau associatif/l'objet JSON qui donne la liste des liens.

Slide 69

quelle est la différence entre @RepositoryRestResource et @RestResource. j'ai l'impression que dans la vidéo vous parlez de l'un et l'autre comme interchangeable..
pour annoter une méthode, il faut utiliser @RestResource. @RepositoryRestResource ne s'emploie que sur une classe.
les deux peuvent s'employer pour annoter une classe, mais la javadoc de @RestResource suggère dans ce cas l'utilisation de @RepositoryRestResource qui est plus récente et a plus d'option.
Donc le transparent 70 :

@RestResource
public interface TypeEntreeRepository
extends JpaRepository<TypeEntree, Long> {
// Empêche la création et la modification de TypeEntree par REST.
@Override
@RestResource(exported = false)
<S extends TypeEntree> S save(S entity);
}
est correct, mais serait plus à jour sous la forme :

@RepositoryRestResource
public interface TypeEntreeRepository
extends JpaRepository<TypeEntree, Long> {
// Empêche la création et la modification de TypeEntree par REST.
@Override
@RestResource(exported = false)
<S extends TypeEntree> S save(S entity);
}
DIVERS

Comment organisez/factorisez vous les controller et html ? Y a t'il des règles/ conseils ?
En gros, les contrôleurs étant des façade, on aura généralement tendance à regrouper les méthodes en fonction des resources utilisées. Donc à avoir plusieurs URLs liées à un contrôleur.

Certaines caractéristiques des contrôleurs, dont je n'ai pas parlé, comme @ModelAttribute pourraient conduire à découper un peu plus les classes - on peut probablement dédier un contrôleur à un use-case complexe.

Un Controller peut avoir plusieures url. On fait un controller par model ? et dans la mesure du possible on fait un html par controller
?
En gros, la découpage est souvent fait par domaine... Assez souvent, un domaine va correspondre à une entité.