Meilleures pratiques pour les DTO entrants et sortants

Question

Je suis confronté à un problème de conception d'API. Considérons le flux suivant :

Comme vous pouvez le voir, j'ai 2 classes pour représenter mon modèle ( SomethingDTO y SomethingResponse ) et 2 classes pour représenter le modèle tiers ( 3rdPartyRequest y 3rdPartyResponse ). J'utilise un mappeur pour fournir une traduction des classes de modèles de 3rdPArty vers mes classes de modèles.

Le problème est que ces 4 classes ont exactement les mêmes attributs.

Dois-je répéter ces attributs dans toutes ces classes ? Devrais-je avoir une seule classe DTO pour l'ensemble du flux ?

Quelle est la meilleure pratique (ou modèle) pour résoudre ce problème ?

Gracias

Answer 1

C'est une question difficile. Être pragmatique ou être correct.

L'approche correcte (à mon avis) est d'avoir une classe différente pour chaque demande/réponse, ce que vous avez fait. En effet, j'essaie de concevoir des applications en utilisant une classe de type Architecture des ports et adaptateurs et utilisent également la conception pilotée par le domaine. L'avantage est que cela donne plus de flexibilité et de clarté dans le scénario où les objets commencent à diverger.

Si les classes ont exactement les mêmes attributs, j'adopterais une approche pragmatique consistant à avoir une classe par couche. Donc une pour votre requête/réponse Web et une pour la tierce partie. Mais en aucun cas, je ne mélangerais deux couches d'intégration (front-end et tierce partie).

Avoir une seule classe pour l'ensemble de la chose sent vraiment mauvais. Comme je l'ai mentionné plus haut, car cela revient à mélanger les couches (ou les ports).

Answer 2

Comme je précédemment répondu L'utilisation des DTOs permet de découpler les modèles de persistance à partir des modèles d'API. Vous semblez donc faire ce qu'il faut.

Le problème est que ces 4 classes ont exactement les mêmes attributs.

C'est toujours une bonne idée de découpler les modèles de votre API des modèles d'une API tierce. Si l'API tierce change leur contrat, vous ne briserez pas votre clients. Utilisez donc des modèles différents pour chaque API.

Et s'en tenir à cadres cartographiques tels que MapStruct pour réduire le code passe-partout. Vous pouvez également envisager Lombok pour générer des getters, setters, equals() , hashcode() y toString() méthodes pour vous.

Dois-je répéter ces attributs dans toutes ces classes ? Devrais-je avoir une seule classe DTO pour l'ensemble du flux ?

Si les modèles de demande et de réponse contiennent tous deux l'élément même ensemble de champs alors vous pouvez commencer par un classe unique pour représenter les données utiles de la demande et de la réponse d'un système de gestion de l'information. chaque API. Lorsque les champs commencent à différer (charge utile de la demande différente de la charge utile de la réponse), vous créez de nouveaux modèles pour représenter chaque charge utile.

À long terme, l'utilisation de modèles distincts pour la demande et la réponse vous donnera de la flexibilité, en vous assurant que vous exposerez et recevrez uniquement les attributs que vous souhaitez.