Bonjour,
Dans le cours Vapor, section Authenticité et sécurité dans le vidéo “Fluent: Inscription d’un utilisateur”. Maxime met un objet Create emboité dans User via son extension. J’ai bien compris que cet objet représente ce que le client envoie.
N’est-il pas meilleure pratique que de passer par des DTO pour les échanges réseau ?
Ou la méthode dans le cours est ce qui doit se faire en Swift ?
Merci d’avance pour votre éclaircissement.
@Med si ça peut te répondre : https://docs.vapor.codes/4.0/fluent/model/#data-transfer-object
Car je ne connais pas le design pattern Data Transfer Object (DTO).
Merci @ThonyF pour ton retour et le lien vers la documentation DTO de Vapor.
À vrai dire les DTO c’est simplement une couche qui représente les données qui vont être échangées sur le réseau pour que ça soit plus léger en données.
Par exemple la classe User qui représente les données (dans sa totalité) de la BDD :
final class User: Model, Content {
static let schema = "users"
@ID(key: .id)
var id: UUID?
@Field(key: "name")
var name: String
@Field(key: “age”)
var age: UInt8
@Field(key: "email")
var email: String
@Parent(key: "adress_id")
var adress: Adress
@Parent(key: "order_id")
var orders: [Order]
…
}
Sur certains affichages au niveau client, on souhaite juste obtenir le nom, l’âge et l’email. Dans ce cas on créer un DTO représentant cet écran.
struct UserLightInformation: Content {
var name: String
var age: UInt8
var email: String
}
Avec cette structure DTO (UserLightInformation), on aura juste les informations nécessaires à l’affichage et non la totalité des données de la classe User qui ne serviront pas tous. Cela rend les données beaucoup plus légères sur le réseau.
L’inconvénient de cette méthode est que cela pourrait prendre beaucoup de temps à mapper dans un sens ou dans l’autre les entités (User) et les DTO (UserLightInformation) et à créer des DTO pour toutes les entités.
C’est pour cela que j’ai demandé s’il n’y avait pas une technique différente en Swift pour y remédier.
Excellente question!
Il faut savoir que tu vas recevoir du JSON dans tous les cas donc le mapping sera inevitable.
L’utilisation de DTO est très pratique pour décoder du JSON en Swift.
L’alternative serait d’utiliser le parser JSON manuellement qui va mapper des tableaux clés-valeurs que tu devras parcourir pour créer tes vrais objets. C’est comme si tu faisais un double mapping (JSON -> Tableaux -> Modèle) alors qu’en utilisant un DTO tu as quelque choses dans ce genre JSON -> DTO (-> Modèle … uniquement si nécessaire).
Dans le cadre d’échange réseaux et d’API, les DTO permettent aussi de garantir une stabilité de l’API indépendante de tes classes du modèle. Tu peux changer tes classes du modèle sans avoir à changer l’API : tu auras des erreurs de compilation lors de la conversion DTO -> Modèle, ce qui est toujours mieux que des erreur de parsing JSON à la réception de requêtes entrantes.
Donc l’utilisation des DTO reste ce qu’il y a de mieux quand c’est nécessaire.
Merci @mbritto pour tes explications complémentaires, qui sont comme toujours excellentes !
Avec plaisir! La question était super intéressante en plus 