Conception du contrat de service (signature des opérations)

Question

Je conçois des services et je voudrais obtenir des commentaires sur les conventions que j'utilise.

Pour toutes les opérations, je définis toujours un objet «contexte» et un «résultat», en raison des avantages suivants:

• Extensibilité: je peux ajouter des paramètres au contexte ou aux objets au résultat sans modifier l'interface
• Compacité: je n'ai qu'un seul objet dans la définition, même si j'ai besoin de nombreux paramètres

Exemple:

[OperationContract]    
DoSomethingResult DoSomething(DoSomethingContext context)

Quoi qu'il en soit, je ne suis pas vraiment sûr que c'est la meilleure façon de le faire pour les raisons suivantes:

• Offres: j'enroule toujours les propriétés de réponse dans un objet. Parfois, l'objet résultat n'a pas de propriétés
• Versioning: WCF a le versioning intégré pour les contrats, et peut-être qu'il pourrait être préférable d'utiliser une version différente pour informer la différence

En fait, j'utilise également la même technique avec des méthodes normales, il serait donc important pour moi d'obtenir des commentaires, des conseils, des critiques, etc.

Merci

Answer 1

Je pense que c'est une façon parfaitement légitime d'écrire vos contrats. J'ai travaillé sur un certain nombre de projets avec ce genre de contrats et c'est un plaisir - très facile pendant le développement (ajoutez simplement une propriété à l'objet et vous avez terminé), un modèle simple et clair qui s'applique à tous services et permet des choses comme une seule méthode de validation pour toutes les opérations.

En réponse à vos préoccupations:

• Je ne pense pas que les frais généraux de créer un objet vide sont du tout significatifs. Ne vous inquiétez pas à moins que cela ne devienne un problème.
• Si l'objet résultat n'a pas de propriétés (c'est-à-dire que vous ne renvoyez rien), retournez simplement void. Vous ne gagnez rien en renvoyant un objet vide.
• Vous pouvez (et devriez probablement) cesser ces objets lorsque vous versionz vos contrats. Ce que vous faites en aucun cas ne vous empêche pas de verser vos objets.

Veuillez noter que les objets de versioning ne signifie pas les modifier en DoSomethingResult_v1, DoSomethingResult_v2 Comme je l'ai déjà vu. Vous devez version avec des espaces de noms; Cela rend les choses plus claires et plus propres. Il suffit de mettre une version dans les espaces de noms XML dans le contrat d'opération et les attributs de membres de données.

Answer 2

Je ne pense pas qu'il y ait des problèmes de performances ici, et le code semble facile à travailler du point de vue des propriétaires de code.

Ma grande préoccupation est qu'il n'est pas du tout clair du point de vue des consommateurs du fonctionnement de votre service. Ils devraient s'appuyer sur des messages de documentation ou d'erreur distincts.

Il serait beaucoup plus facile pour une personne qui ne soit pas familière avec votre code (c'est-à-dire qu'il vient de télécharger le WSDL) pour consommer votre service si les paramètres dont il exigeaient étaient déclarés. Vous obtenez également un bon degré de validation hors de la boîte.

Pour illustrer:

[OperationContract]     
DoSomethingResult DoSomething(DoSomethingContext context) 

contre

[OperationContract]   
[FaultContract(typeof(CustomerNotFoundFault))]   
Customer GetCustomer(UInt32 customerId) 

Ce point est principalement pertinent pour la conception des API. Là où cela n'est pas si pertinent, c'est l'endroit où vous êtes à la fois l'auteur et le consommateur du service.

Je soutiens totalement la suggestion de Kirk Broadhurst d'utiliser des espaces de noms pour le versioning. J'utilise cela et cela fonctionne bien.

Edit: Lors d'une deuxième lecture, je pense que j'ai mal lu votre message. Je suppose ici que votre paramètre et vos objets de valeur de retour étaient un objet générique que vous utilisez sur tous les services. Si en effet, ils sont spécifiques à chaque service, c'est une grande approche que j'ai utilisée avec succès à plusieurs reprises. Vous en ferez bien.