R6.05 - Prog. Frameworks : Spring boot

{
  _id: ObjectId("abcdef11111111"),
  lastname: "dupond",
  firstname: "jean",
  class: 2020
}
{
  _id: ObjectId("abcdef22222222"),
  lastname: "martin",
  firstname: "jeanne",
  class: 2020
}
{
  _id: ObjectId("ababab45678902"),
  name: "algo",
  students: [ ObjectId("abcdef11111111"), ObjectId("abcdef22222222") ]
}

@Document("students")
public class Student {
  @Id
  private String id;
  private String firstname;
  private String lastname;
  private int class; 
  ... // getters+setters
}

@Document("courses")
public class Course {
  @Id
  private String id;
  private String name;
  @DocumentReference
  private List<Student> students;
  ... // getters+setters
}

public interface StudentsRepository extends MongoRepository<Student, String> {

    Optional<Student> findByLastname(String lastname);
    List<Student> findAllByClassLessThan(int class);
    Page<Student> findAllByFirstnameLike(String lastname, Pageable pageable);

}

public class StudentDTO {
  private String id;
  private String firstname;
  private String lastname;
  private Integer class; 
  public StudentDTO(Student student) { ... }
  ... // getters+setters
}

public class Course {
  private String id;
  private String name;
  private List<StudentDTO> students;
  public CourseDTO(Course course) { ... }
  ... // getters+setters
}

@Document("courses")
public class Course {
  @Id
  private String id;
  private String name;
  private List<String> students;
  ... // getters+setters
}

L'avantage de cette solution est qu'il est ainsi possible de renvoyer au client un objet CourseDTO, construit à partir d'un objet Course, et qui ne contient que les ids des étudiants. De cette façon, le client peut décider ensuite de demander à l'API les étudiants uniquement quand il en a besoin. L'inconvénient est que l'on reporte le travail de faire le lien au niveau du client et que l'on perd la capacité de récupérer les étudiants en même temps qu'un cours, ce qui serait peut être utile dans certains cas.

Heureusement, il existe une solution moyennement complexe pour effacer cet inconvénient pour proposer au client un moyen de soit récupérer uniquement des ids, soit récupérer des informations complètes. Sur l'exemple de Course et Student, cela implique :

• de créer une classe StudentDTO avec au moins :
  • un constructeur qui initialise uniquement l'id et laisse les autres attributs à null.
  • un constructeur qui initialise complètement les attributs à partir d'une entité Student.
• de créer une classe CourseDTO avec un attribut List<StudentDTO> annoté avec @JsonSerialiaze (cf. ci-dessous) et au moins :
  • un constructeur prenant uniquement en paramètre une entité Course, qui initialise la liste avec des instances de StudentDTO dont seul l'id est initialisé (cf. 1er constructeur mentionné ci-dessus)
  • un constructeur prenant en paramètre une entité Course et une List<Student>, qui initialise la liste avec des instance de StudentDTO complètement initialisées (cf. 2nd constructeur ci-dessus)
• de créer une classe de sérialisation spécifique pour le type List<StudentDTO>, qui permette de renvoyer au client soit les informations complètes soit uniquement des ids, en fonction du nombre d'informations se trouvant dans les objets StudentDTO.
• d'ajouter deux gestionnaires de route dans CourseController, pour renvoyer au client un objet CourseDTO plus ou moins complet. Dans les deux cas, les méthodes commencent par récupérer une entité Course grâce à CourseService puis :
  
  • pour la première route, la méthode utilise simplement le premier constructeur de CourseDTO mentionné ci-dessus, et renvoie directement l'instance ansi créée,
  • pour la deuxième route, la méthode parcours la List<String> students de l'entité Course et pour chaque élément, récupère une entité Student grâce à StudentsService. Toutes ces instances de Student sont mises dans une liste, avant d'appeler le second constructeur de CourseDTO mentionné ci-dessus.

L'archive de démonstration contient une mise en application de ce principe avec des organisations, contenant des équipes, contenant elles-mêmes des héros.

 2.4°/ Requêtes spéciales

Dans certains cas, il n'est pas possible d'exprimer une requête avec simplement un nom de méthode dans un repository. C'est le cas par exemple quand on veut chercher des documents en fonction d'informations se trouvant dans un tableau de sous-documents. Heureusement, il est possible de décrire la requête directement avant le nom de la méthode grâce à l'annotation @Query.

Exemple avec un document bankuser, contenant un tableau de sous-documents dans le champ accounts :

{
  _id: ObjectId("abcdef11111111"),
  login: "jdupond",
  pass: "azer",
  accounts : [
    { number: "abcdef1000", amount: 1000 },
    { number: "abcdef2000", amount: 342 }
  ]
}

class BankUserRepository extends MongoRepository<BankUser, String> {
  @Query(value=" ")
  List<BankUser> findAllBy...(int amount);
}