Mot du traducteur

Question

Dans un travail précédent, mon responsable a suggéré l'utilisation d'un modèle Traducteur pour convertir des données d'un DataTable en objets. Fondamentalement, la classe Translator ne disposait que de méthodes statiques (c'est-à-dire de classe), donc il s'agissait d'une agrégation d'appels de fonctions. Mon approche initiale consistait à implémenter des constructeurs pour chaque objet pouvant prendre une ligne DataTable comme argument et créer une instance correspondant aux données. Il a déclaré que la classe Translator avait été suggérée par Microsoft et qu'elle offrait une meilleure modularité du code. Je peux voir ce point, mais en même temps cela semble être une approche très non-OO (bien que le modèle de visiteur a des caractéristiques similaires).

L'un de vous a-t-il utilisé ce modèle, et qu'en pensez-vous? avantages et inconvénients?

Answer 1

A partir de C2.Com, il apparaît que le modèle Translator est une implémentation non-OOP du modèle de visiteur. Il note et la fin de l'article quelques-uns des inconvénients, y compris le fait que dans la sémantique OOP il est difficile d'exprimer (mais pas de code), en d'autres termes, cela fonctionnera bien mais peut ne pas avoir beaucoup de sens si vous êtes en utilisant OOP pur pour le reste de votre code.

Answer 2

Si vous pouvez effectuer le mappage sans aucune dépendance externe, il est inutile d'utiliser autre chose qu'une méthode statique.

Answer 3

Peut-être qu'il me manque quelque chose, mais pourquoi ne pas simplement utiliser linq? Quoi qu'il en soit, le TranslatorPattern consiste à changer la structure de données d'une représentation à une autre structure équivalente. Ici http://c2.com/cgi/wiki?TranslatorPattern est l'information la plus profonde à ce sujet.

Answer 4

Je pense que vous parlez de Entity Translator. Je pense que le traducteur dans ce scénario est naturellement une méthode statique. Où il vit est une question d'esthétique. Il devrait également être assez facilement testé unitairement car il ne devrait avoir que des dépendances sur deux structures de données qu'il traduit entre. Le type de sons comme un autre nom pour leur "contrat de données" est DTO (Data Transfer Object).