Un DTO peut-il avoir des méthodes d'instance renvoyant des valeurs dérivées?

Est-il toujours acceptable pour un DTO d'avoir des méthodes d'instance qui retournent des valeurs dérivées basées sur les données du DTO? Ou les DTO devraient-ils être des conteneurs de données purs sans méthodes supplémentaires (autres que des getters/setters)?Un DTO peut-il avoir des méthodes d'instance renvoyant des valeurs dérivées?

Le puriste en moi dit qu'il est loin d'être facile pour la logique métier de s'insinuer dans de telles méthodes. Cependant, si (par exemple) un DTO est partagé entre des couches d'application, alors il y a peut-être un argument pour avoir de telles méthodes sur le DTO.

Quelle est votre opinion à ce sujet? Y a-t-il des situations où cela est acceptable ou faut-il éviter ce genre de choses? Et pourquoi/pourquoi pas?

Source

2010-02-12 KarstenF

bonne question, j'étais sur le point de demander! – andy

Les DTO ne devraient pas avoir de comportement, ils sont de simples conteneurs pour transporter des données à travers les limites de processus et devraient être constitués uniquement de setters/getters.

Il devrait être évité à tout prix sinon il serait interprété comme une mauvaise application du modèle DTO.

Source

2010-02-12 22:05:15 David

La plupart des livres sur les pratiques exemplaires que j'ai consultés au cours de la dernière année ont déconseillé le DTO. – Woot4Moo

La question était spécifiquement sur le modèle DTO pas si elle devrait être utilisée ou non. Le problème avec le DTO est qu'il est mal appliqué dans beaucoup de situations, par ex. où il n'y a pas de limite de processus! C'est la raison pour laquelle il est arrivé, l'agrégation de données à partir d'un processus à distance pour économiser les voyages aller-retour coûteux. – David

Dois-je utiliser @override compareTo dans un DTO ou n'est pas recommandé? Est-il préférable d'utiliser un emballage à cette fin? –

Un DTO peut-il avoir des méthodes d'instance renvoyant des valeurs dérivées?

Répondre

Questions connexes