ce qui est un bon modèle pour la conversion entre les entités mise en veille prolongée et des objets de transfert de données?

Question

J'ai eu des questions et des préoccupations similaires quant à la façon de convertir entre les entités Hibernate et le transfert de données des objets à renvoyer par un service Web que sont abordées dans cette question:

Est-ce en utilisant des objets de transfert de données dans EJB3 considéré comme le meilleur pratique

L'un des facteurs mentionnés ici est que si le modèle change de domaine, un ensemble de DTO protégera les consommateurs dans le cas d'un service Web.

Même si il semble que cela ajoutera une quantité importante de code à mon projet, ce raisonnement semble son.

Y at-il un bon modèle de conception que je peux utiliser pour convertir une entité Hibernate (qui implémente une interface) à un DTO qui implémente la même interface?

Donc, en supposant les deux éléments suivants mettre en œuvre « Livre », je aurais besoin de convertir un BookEntity.class à un BookDTO.class afin que je puisse laisser JAXB sérialisation et de retour.

Encore une fois, cette perspective tout me semble douteuse, mais s'il y a de bons modèles là-bas pour aider à faire face à cette conversion, j'aimerais obtenir un aperçu.

Y at-il peut-être une façon intéressante de convertir par réflexion? Ou un modèle « constructeur » que je ne pense pas à?

Devrais-je simplement ignorer le modèle de DTO et passer des entités autour?

Answer 1

  

Devrais-je simplement ignorer le motif DTO   et passer des entités autour?

Ma préférence est généralement « oui ». Je ne aime pas l'idée des hiérarchies parallèles créées juste pour le plaisir de la pureté architecturale ou de la couche.

Le motif initial pour le motif DTO est chattiness excessive dans les EJB 1.0 et 2.0 des applications EJB lors du passage de l'entité au niveau de la vue. La solution était de mettre l'état de bean entité dans un DTO.

Une autre raison qui est habituellement donnée pour la création DTO est d'interdire la modification par la couche de vue. DTO sont des objets immuables dans ce cas, sans comportement. Ils font des données, mais rien de ferry à la couche de vue.

Je dirais que DTO est un modèle J2EE Core qui est devenu un anti-modèle.

Je me rends compte que certaines personnes seraient en désaccord. Je propose simplement mon avis. Ce n'est pas la seule façon de le faire, ni nécessairement la « bonne ». Il est ma préférence.

Answer 2

Il doit être vue à contre-courant parmi tous les coups de pied joyeux de la DTO.

tl;. Dr - Il est parfois encore utile

L'avantage de la DTO est que vous ne devez pas ajouter des annotations zillion à vos classes de domaine.

Vous commencez avec @Entity. Pas si mal. Mais alors vous avez besoin JAXB donc vous ajoutez @XMLElement etc - et vous avez besoin JSON afin que vous ajoutez des choses comme @JsonManagedReference pour Jackson de faire la bonne chose avec des relations, vous ajoutez etc etc etc ad infinitum.

Très vite votre POJO est pas si simple plus. En savoir plus sur "Driven Design domaine" quelque temps.

En outre, vous pouvez « filtrer » des propriétés que vous ne voulez pas le point de vue de connaître.

Answer 3

Il ne faut pas oublier que les objets d'entité ne sont pas faciles à gérer quand ils sont dans un état géré. Cela rend leur passage à l'interface graphique forme problématique. Pour être plus précis, les objets enfants sont traités avec impatience. Cela ne peut pas être fait à la session, des exceptions cousing. Donc, ils ont soit être expulsés (détaché) du gestionnaire d'entités de elles doivent être converties en DTO appropriées. À moins Evidement, il y a un modèle, que je ne suis pas au courant, que je serais très heureux de savoir.

Answer 4

Pour créer rapidement un "sosie" DTO, sans un tas de double get / code jeu, vous pouvez utiliser BeanUtils.copyProperties . Cette aide de fonction copier rapidement les données de DAO à la classe DTO. Rappelez-vous qu'il ya plus d'une bibliothèques communes prennent en charge BeanUtils.copyProperties, mais leur syntaxe ne sont pas les mêmes.

Answer 5

Je sais que c'est une vieille question, mais a pensé que je voudrais ajouter une réponse en offrant un cadre d'aide au cas où quelqu'un d'autre est la lutte contre ce problème.

Notre projet a JAXB annoté POJO qui sont séparés des POJO JPA annoté. Notre équipe était en train de débattre de la meilleure façon de déplacer des données entre les deux objets (en fait des structures de données).

Voici une option pour les gens à considérer:

Nous avons trouvé et expérimentent Dozer qui poignées (1) même nom, (2) mapping XML et (3) conversions personnalisées en tant que moyen de copier des données entre deux POJO.

Il a été très facile à utiliser jusqu'à présent.