2009-11-06 9 views
4

Je suis curieux de savoir ce que la communauté ressent à ce sujet. J'ai récemment abordé la question avec un scénario NHibernate/WCF (les entités ont persisté au niveau de la couche de service) et j'ai réalisé que je pouvais aller dans la mauvaise direction ici.DTO vs Sérialisation des Entités Persistées

Ma question est claire, lorsque vous utilisez un graphique d'objet persistant (NHibernate, LINQ to SQL, etc) derrière un service web (WCF dans ce scénario), préférez-vous envoyer ces entités sur le réseau? Ou pourriez-vous créer un ensemble de DTO plus légers (sans références cycliques) à travers?

Répondre

8

DTO. Utiliser AutoMapper pour le mappage objet-objet

+1

+1 pour la mention AutoMapper! –

+0

Moi j'aime vraiment beaucoup !!! – epitka

1

J'ai presque toujours créé des dtos pour transférer sur le réseau et utiliser des entités richter sur mon serveur et mon client. Sur le client, ils auront une logique de présentation commune tandis que sur le serveur ils auront une logique métier. La cartographie entre les dtos et les entités peut être stupide, mais cela doit se produire. Des outils comme AutoMapper vous aident.

1

Si vous me demandez, j'envoie des entités sérialisées d'un service Web au monde extérieur? alors la réponse est définitivement non, vous obtiendrez une interopérabilité minimale si vous faites cela. Les DTO aident à résoudre ce problème en définissant un ensemble d '«objets» qui peuvent être instanciés dans n'importe quel langage, que vous utilisiez C#, Java, Javascript ou autre chose.

+0

Je suis d'accord. C'est en fait un service interne (nos applications intranet l'utilisent, je sais que je n'ai pas spécifié), mais le concept reste vrai. –

3

J'ai été dans ce scénario plusieurs fois avant et peut parler de l'expérience des deux côtés. À l'origine, je ne faisais que sérialiser mes entités et les envoyer telles quelles. Cela fonctionnait bien d'un point de vue fonctionnel, mais plus je l'examinais, plus je me rendais compte que j'envoyais plus de données que j'en avais besoin et que je perdais la possibilité de varier la mise en œuvre de chaque côté. Dans les applications de service suivantes, j'ai pris l'habitude de créer des DTO dont le seul but est d'obtenir des données depuis et vers le service Web. En dehors de tout interop, avoir à penser à tous les champs qui sont envoyés sur le fil est très utile (pour moi) pour s'assurer que je n'envoie pas de données qui ne sont pas nécessaires ou pire, ne devrait pas obtenir jusqu'au client.

Comme d'autres l'ont mentionné, AutoMapper est un excellent outil pour l'entité à la cartographie DTO.

1

J'ai toujours eu des problèmes pour envoyer des objets nHibernate sur le réseau. Particulièrement si vous utilisez un modèle ActiveRecord. et/ou si votre objet a des liens avec la session (beurk). Un autre résultat désagréable est que nHibernate peut essayer de charger l'objet à l'entrée de la méthode (avant que vous ne puissiez y accéder), ce qui peut également causer des problèmes.

Alors ... obtenir le message ici? problèmes, problèmes problèmes ... DTO tout le chemin