Est-ce une bonne pratique d'avoir des objets DTO profondément intégrés dans le code?

Question

Je construis une application assez volumineuse qui utilise le modèle de conception DAO/DTO pour obtenir des données à partir d'une base de données. Dans l'application, un DTO particulier est devenu la «structure de données de base» en ce sens qu'il est référencé tout au long du projet. Je me demande si c'est une bonne pratique d'avoir ce DTO si profondément intégré dans le projet, ou devrais-je avoir une sorte de couche de conversion où je convertis les DTO en objets non-DTO?

Je peux voir les raisons pour et contre avoir cette couche de conversion. Par exemple, si nous avons la couche de conversion, alors: 1) Des changements drastiques dans le DTO peuvent provoquer des erreurs dans tout le projet, ce qui fait que la couche de conversion isole l'erreur à un seul point du code. 2) Je suis capable d'ajouter une logique supplémentaire à la structure de données de base qui ne peut pas être ajoutée au DTO car elle est générée automatiquement.

Cependant, je vois des inconvénients à avoir une couche de conversion aussi: 1) Le code de conversion DTO doit être maintenu cohérent à chaque changement de DTO. Cela ajoute une autre étape que le programmeur doit être conscient de et est donc plus sujette aux erreurs. 2) Cela conduit également à la duplication de code puisque, pour la plupart, vous copiez les accesseurs du DTO.

Quelle est la meilleure route à faire? DTOs partout ou une couche de conversion? Quelqu'un peut-il me guider dans la bonne direction?

Answer 1

Je considèrerais DTO comme un anti-pattern, une relique à une époque où la persistance d'EJB 1.0 était si bavarde que les DTO étaient nécessaires pour réduire le trafic réseau. Maintenant je dirais créer des objets modèles et dormir la nuit. Rendez-les immuables si vous le pouvez et ne vous inquiétez pas des DTO. Les traductions pour des raisons de pureté architecturale gaspillent des cycles d'unité centrale sans fournir beaucoup de valeur.

Answer 2

Je pense que le nom donnerait l'intention: Objet de transfert de données. Transfert de données.

L'idée derrière les DTO est que vous les utilisez pour encapsuler des données que vous envoyez en dehors de votre modèle de domaine, à une autre couche par exemple. Vous n'exposez pas votre logique, vous envoyez juste des données. Si vos objets de domaine sont des objets DTO, vous exposez votre logique de domaine en dehors de votre modèle de domaine ou vous gardez votre logique de domaine ailleurs que dans vos objets de domaine. Ou les deux.

J'ai été sur des projets qui les ont séparés et j'ai été sur un projet qui les a mélangés. Je ne peux vraiment pas recommander de les mélanger. Vos couches commencent à se mélanger, comme le tie-dye.