WCF - Objets de domaine et IExtensibleDataObject

Question

Scénario typique.Nous utilisons des services Web XML à l'ancienne internally pour communiquer entre une batterie de serveurs et plusieurs serveurs distribués et clientèle locale.Aucun tiers impliqué, uniquement nos applications utilisées par nous-mêmes et par nos clients.

Nous réfléchissons actuellement à passer de XML WS à un WCF/object-based modèle et ont expérimenté diverses approches.L'un d'eux consiste à transférer les objets/agrégats du domaine directement via le réseau, en invoquant éventuellement les attributs DataContract sur ceux-ci.

En utilisant IExtensibleDataObject et un DataContract en utilisant la propriété Order sur le DataMembers, nous devrions être capables de résoudre de simples problèmes de version de propriété (rappelez-vous que nous contrôlons tous les clients et pouvons facilement les mettre à jour de force).

J'entends constamment dire que nous devrions utiliser des objets de transfert de données dédiés au transfert uniquement (DTOs) sur le fil.

Pourquoi?Y a-t-il encore une raison de le faire ?Nous utilisons le même modèle de domaine côté serveur et côté client, bien sûr, en pré-remplissant les collections, etc.uniquement lorsqu'il est jugé droit et "nécessaire". Les propriétés de collecte utilisent le principe du localisateur de service et le CIO pour invoquer soit un NHibernate-based "service" pour récupérer les données directement (côté serveur), et un WCF client "service" côté client pour parler au WCF batterie de serveurs.

Alors, pourquoi devons-nous utiliser DTOs?

Answer 1

D'après mon expérience, les DTO sont les plus utiles pour :

1. Définir strictement ce qui sera envoyé par fil et avoir un type spécifiquement dédié à cette définition.
2. Isoler le reste de votre application, client et serveur, des modifications futures.
3. Interopérabilité avec les systèmes non-.Net.Les DTO ne sont certainement pas une exigence, mais ils facilitent la conception de types « sûrs ».

Dans votre scénario, ces caractéristiques de conception n’ont peut-être pas beaucoup d’importance.J'ai utilisé WCF avec des DTO stricts et des objets de domaine partagés et dans les deux scénarios, cela a très bien fonctionné.La seule chose que j'ai remarquée lors de l'envoi d'objets de domaine par fil, c'est que j'avais tendance à envoyer plus de données (et de manière inattendue) que ce dont j'avais besoin.Cela était probablement plus dû à mon manque d'expérience avec WCF qu'à toute autre chose ;mais c'est quelque chose dont vous devez absolument vous méfier si vous choisissez de suivre cette voie.

Answer 2

Ayant travaillé avec les deux approches (objets de domaine partagés et DTO), je dirais que le gros problème avec les objets de domaine partagés est que vous ne contrôlez pas tous les clients, mais d'après mes expériences passées, j'utiliserais généralement les DTO à moins que la vitesse de développement ne soit bonne. l'essence.

S'il y a une chance que vous ne contrôliez pas toujours les clients, je recommanderais certainement les DTO, car dès que vous partagez vos objets de domaine avec l'application client de quelqu'un d'autre, vous commencez à lier vos éléments internes au cycle de développement de quelqu'un d'autre.

J'ai également trouvé les DTO utiles lorsque nous travaillons dans un environnement de service versionné, ce qui nous a permis de modifier radicalement les composants internes de notre application tout en acceptant les appels vers les anciennes versions de nos interfaces de service.

Enfin, si vous disposez de nombreuses applications clientes, il peut également être avantageux d'utiliser des DTO, car vous êtes alors protégé par un service facilement versionnable.