Contenu du cours

Backend Spring Boot

1. Notions de Base du Développement Backend

Introduction au Backend Comment Fonctionne HTTP HTTP/HTTPS Code de Statut Formats de Données : JSON et XML

2. Notions de Base de Spring Boot

Introduction à Spring Structure du Projet Spring MVC IoC et DI Architecture à Trois Niveaux Tâche de Printemps

3. API RESTful

Qu'est-ce Que REST?Principes de Base de REST Écrire Votre Propre API REST Travailler avec DTO Gestion des Exceptions Swagger Tester l'API RESTful

4. Travailler avec des Bases de Données

Introduction aux Bases de Données Relationnelles Connexion à une Base de Données MySQL Migrations de Base de Données Travailler avec ORM : JPA et Hibernate Ajouter la Base de Données à Notre Application Transactions

5. Tester les Applications Backend

Fondamentaux des Tests des Applications Backend Tests Modulaires avec JUnit Mockito Défi : Test Unitaire Résumé du Cours

Travailler avec DTO

L'utilisation des DTOs simplifie et optimise l'échange de données en excluant les champs inutiles et en fournissant uniquement les données dont un client spécifique a réellement besoin.

Les DTOs dans cet exemple servent à limiter l'échange de données entre le client et le serveur. Le ResponseBookDTO est utilisé pour envoyer uniquement les données nécessaires (name, author, price) au client, tandis que le RequestBookDTO permet aux clients d'envoyer les données requises (date, name, author, price) au serveur.

Le principal avantage de l'utilisation des DTOs est qu'ils aident à séparer les données de la logique métier et permettent de contrôler quelles données sont transférées entre les couches de l'application ou incluses dans les messages de réponse HTTP.

Où s'applique le DTO ?

DTOs sont utilisés lorsqu'il est nécessaire de présenter des données dans un format spécifique, comme pour transférer des données à un client ou recevoir des informations d'un client dans le contexte d'une API REST.

Ceci est également pertinent lors de l'interaction entre les couches dans une architecture multi-couches, où les données sont transmises entre les services et les référentiels.

Exemple réel

Imaginez que vous développez une application pour une boutique en ligne. Vous avez une entité appelée Product, qui comprend beaucoup d'informations : name, description, price, production date, discounts, etc.

Un client demandant une liste de produits n'a pas besoin de toutes ces informations. Au lieu de cela, vous pouvez créer un objet DTO qui contient uniquement les champs nécessaires (comme le nom et le prix) pour envoyer ces données au client.

Exemple d'utilisation

Dans notre application, le modèle principal est Book, qui est envoyé par le client et retourné par le serveur.

Main


              12345678
            
@Getter
@Setter
public class Book {
    private String id;
    private String name;
    private String author;
    private String price;
}

Cependant, ne semble-t-il pas que le champ id est inutile lors de la réception des données du client, puisqu'il est généré au niveau du dépôt. Nous aurons besoin de l'id uniquement lors du retour d'une réponse.

C'est là que les DTOs viennent à la rescousse. Ils nous permettent de séparer la logique et de créer différentes versions du modèle Book pour les requêtes et les réponses, en excluant les champs inutiles comme id là où c'est approprié.

Dans un DTO, un objet avec le préfixe request est utilisé pour envoyer des données du client au serveur, tandis qu'un objet avec le préfixe response est utilisé pour envoyer des données du serveur au client. Cette séparation garantit que seules les données nécessaires sont échangées, améliorant à la fois la sécurité et l'efficacité.

BookRequestDTO

BookResponseDTO


              12345
            
public class BookRequestDTO {
    private String name;
    private String author;
    private String price;
}

Nous avons maintenant deux DTOs : un pour recevoir les requêtes BookRequestDTO et un autre pour envoyer les réponses BookResponseDTO.

Vous pouvez remarquer que BookResponseDTO et notre modèle Book sont identiques, ce qui soulève la question : pourquoi créer un DTO séparé si nous pouvons simplement utiliser le modèle Book ?

La raison est que si nous décidons plus tard d'ajouter des informations supplémentaires qui ne sont nécessaires qu'au niveau du service, notre modèle Book finirait par transmettre des données inutiles au niveau du référentiel, nous obligeant à les filtrer d'une manière ou d'une autre.

Mapper

Pour transformer commodément des objets d'un type à un autre, nous utilisons une bibliothèque spécialisée.

Nous pouvons créer une classe distincte où nous définissons des méthodes statiques et implémentons la logique pour convertir des objets entre types.

MapperBook


              1234567891011
            
public class MapperBook {
    private static final ModelMapper mapper = new ModelMapper();

    public static Book dtoRequestToModel(BookRequestDTO dto) {
        return mapper.map(dto, Book.class);
    }

    public static BookResponseDTO modelToResponseDto(Book book) {
        return mapper.map(book, BookResponseDTO.class);
    }
}

Dans ce code, la classe MapperBook utilise la bibliothèque ModelMapper pour la transformation automatique des objets.

Il contient deux méthodes : la première est dtoRequestToModel(), qui transforme un objet BookRequestDTO en un modèle Book en utilisant la méthode map, et la seconde est modelToResponseDto(), qui convertit un modèle Book en un objet BookResponseDTO.

Grâce à ModelMapper, le processus de transformation d'objet devient plus simple et plus pratique, éliminant le besoin de copier manuellement les champs.

Ajouter un DTO à notre application

Résumé

DTO (Data Transfer Object) est un objet simple conçu pour transférer des données entre les couches ou composants d'une application.

Dans le contexte d'une architecture à trois niveaux, le DTO joue un rôle crucial en assurant la séparation des couches et en fournissant un moyen efficace pour échanger des données entre elles.

Ainsi, utiliser un DTO devient une solution optimale lorsqu'il est nécessaire de gérer l'information entre différentes parties d'une application, évitant le transfert de données inutiles ou non pertinentes.