2010-11-19 21 views
3

Dans notre système, nous récupérons les beans entités gérés ORM à partir de la base de données (en utilisant hibernate), puis nous les copions sur les beans DTO pour les envoyer à l'interface utilisateur.Mettre automatiquement à jour/copier/hériter des javadocs DTO de la classe d'entités

La plupart des propriétés sur le DTO ont le même nom que sur l'entité, mais les types de retour sont souvent différents car les entités référencées doivent être converties pour stocker uniquement l'ID ou un autre DTO.

Dans mon univers de rêve idéal, lorsque j'ai édité les javadocs pour l'entité, les javadocs sur les méthodes du même nom dans le DTO seraient mis à jour pour correspondre. Cela pourrait être fait via un outil de construction ou un plugin eclipse.

Est-ce que quelqu'un a déjà vu quelque chose comme ça?

+0

De quelles méthodes parlons-nous? Si c'est un DTO, c'est probablement une structure de données, sans logique métier. – slnowak

Répondre

1

Eh bien c'est certainement possible. Ce dont vous avez besoin est un analyseur de code source, je recommanderais javaparser.

Écrivez deux Visitors, l'un pour lire les JavaDocs, l'autre pour les écrire. Dans les deux cas, vous aurez probablement commencer par VoidVisitorAdapter et overrride public void visit(MethodDeclaration n, A arg) et public void visit(JavadocComment n, A arg)

Faire tout cela accessible à partir d'une classe principale et appellent cette classe principale via Maven (Exec-Maven-Plugin) ou fourmi (Java Task) lors de la construction.

+0

Merci, c'est la seule réponse et en théorie ça devrait marcher. Merci. –

-1

Je pense que ce que vous voulez peut être déraisonnable.

Un DTO n'est pas supposé être mappé à une entité. Si tout de même, pourquoi avez-vous besoin d'un DTO?

Le nom d'une entité est généralement mappé à un nom de table et les champs sont mappés à une colonne. Si vous avez le nom du champ de l'entité, vous pouvez facilement accéder à l'objet table dans un système ORM. Ce n'est pas sécurisé.

En outre, un DTO est supposé être flexible pour s'adapter aux besoins de l'interface utilisateur et aux autres besoins de la couche. Il s'agit donc de transfert de données, de transformation, de combinaison, de moins de champs qu'une entité et plus encore.

E.g. Vous pouvez combiner 4 entités ou les données de la vue dans un DTO pour un appel de service Web distant. En raison du traitement des céréales secondaires, il s'agit d'un problème de performance. En conclusion, s'il s'agit d'une application Java EE de niveau entreprise, un DTO est indispensable. Ne pas copier le nom ou avoir une entité très dépendante, mais dériver de l'entité.