Ça vaut le coup d'utiliser des getters et setters dans les DTO? (C++)

Je dois écrire un tas de DTO (Data Transfer Objects) - leur seul but est de transférer des données entre application (s) client et l'application serveur, de sorte qu'ils ont un tas de propriétés, une fonction de sérialisation et un fonction de désérialisation.Ça vaut le coup d'utiliser des getters et setters dans les DTO? (C++)

Quand j'ai vu des DTO, ils ont souvent des getters et des setters, mais est-ce que c'est leur but pour ces types de cours? Je me demandais si je mettrais jamais une validation ou des calculs dans les méthodes, mais je ne pense probablement pas que cela semble aller au-delà de leur objectif. Au niveau du serveur, la couche de gestion gère la logique, et dans le client, les DTO seront simplement utilisés dans les modèles de vue (et pour envoyer des données au serveur).

En supposant que je m'occupe de tout cela correctement, que pensent les gens?

Merci!

EDIT: ET si oui, est-ce que leur problème serait de mettre l'implémentation get/set dans la définition de classe? Enregistre la répétition de tout dans le fichier cpp ...

Source

2010-11-18 Mark

J'étais sûr que vous parliez de C# ici. Par curiosité, comment sérialisez-vous vos classes C++? –

À quoi ressemblent vos objets dans le code? –

@Daniel: Quand sérialisation est appelée, chaque propriété est ajoutée sous sa forme binaire dans un tampon de données croissable (à peu près une copie binaire pour ints par exemple). Des choses simples vraiment - Je code aussi un petit en-tête devant chaque propriété pour permettre la désérialisation des données manquantes/inattendues sans causer de problème (peut-être parce qu'une autre version du DTO est sérialisée à l'autre extrémité). Tout fonctionne bien et je l'ai utilisé dans plusieurs projets. Je peux y ajouter un mécanisme XML pour permettre aux objets d'aller plus facilement vers des logiciels tiers (mais avec beaucoup moins d'efficacité). – Mark

Si vous avez une classe dont le but explicite est simplement de stocker ses variables membres en un seul endroit, vous pouvez aussi les rendre toutes publiques.

Source

2010-11-18 12:51:51 Puppy

Deuxièmement, cela ressemble à un travail pour vieux 'struct' plaine. –

Beaucoup d'exemples de DTO ici semblent avoir des getters et des setters mais je pense qu'ils sont tous des exemples de C# où il est beaucoup plus facile de définir des propriétés (d'après ce que je peux voir). Tendant à se mettre d'accord cependant sur la structure plaine ancienne, bien que les méthodes de sérialisation seraient encore là, donc pas juste une structure malheureusement. – Mark

L'objet n'exigerait probablement pas de destructeur (vous avez seulement besoin d'un destructeur si vous avez besoin de nettoyer les ressources, par exemple des pointeurs, mais si vous numérotez un pointeur, vous demandez simplement des problèmes). Il est probablement agréable d'avoir des constructeurs de sucre de syntaxe, mais rien de vraiment nécessaire. Si les données sont simplement un objet POD (Plain Old Data) pour transporter des données, il est possible d'être struct (classe entièrement publique). Toutefois, en fonction de votre conception, vous pouvez envisager d'ajouter un comportement, par ex. une méthode .action(), qui sait comment intégrer les données qu'elle transporte à votre objet Model actuel; plutôt que d'avoir le modèle actuel intégrant ces changements lui-même. En effet, le DTO peut être considéré comme faisant partie du contrôleur (entrée) au lieu d'une partie du modèle (données).

Dans tous les cas, dans n'importe quelle langue, un getter/setter est un signe de mauvaise encapsulation. Il n'est pas OOP d'avoir un getter/setter pour chaque champs d'instance. Objects should be Rich, not Anemic. Si vous voulez vraiment un objet anémique, passez le getter/setter et allez directement à la structure POD full-public; Il n'y a presque aucun avantage à utiliser getter/setter sur une structure entièrement publique, sauf que cela complique le code, ce qui peut vous donner une meilleure note si votre lieu de travail utilise des lignes de code comme mesure de productivité.

Source

2010-11-18 13:07:55

D'accord sur les objets riches, mais je pense que les DTO sont un cas particulier. La seule autre façon que je puisse penser est de faire en sorte que les objets riches spécifiques à l'application à chaque extrémité de la séparation physique aient les propriétés et les méthodes de sérialisation/désérialisation que le DTO aurait, mais cette IMHO compliquerait les choses pour éviter d'avoir classe qui peut être utilisée facilement à chaque extrémité. Sûrement meilleur que le DTO devienne une propriété de l'objet riche à la place? – Mark

Je suppose qu'il est presque comme le DTO est une classe partielle qui devient entière dans chaque application lorsque augmenté d'une classe riche. Désolé de penser à haute voix, pourrait être non-sens ;-) – Mark

@Mark: Je pense qu'il existe deux solution tout aussi bonne 1) est d'avoir un riche DTO avec des méthodes * riches *, par exemple. .send(), .serialize(), .deserialize(), .apply(), etc 2) structure publique DTO, éventuellement avec quelques * riches * méthodes (.serialize) et complétées avec un wrapper riche (.send). Le premier est plus simple, le second permet à plusieurs wrappers partageant le même DTO ou plusieurs DTO partageant le même wrapper. Ce que je préconise est d'avoir un setter public et getter pour chaque champ d'instance privée, ce qui complique trop le code pour un gain nul. –

Ça vaut le coup d'utiliser des getters et setters dans les DTO? (C++)

Répondre

Questions connexes