Quels sont les avantages et inconvénients de faire consommer un service WCF par le client en ajoutant une référence au service (et tout est généré pour vous) ou en demandant au client d'implémenter une interface partagée et de devoir coder manuellement la classe?WCF Exposer des métadonnées ou demander au client d'implémenter l'interface?
Merci!
En général, si vous n'utilisez pas la génération de code, vous devrez écrire à la main ce qui serait autrement généré pour vous. Le «problème de maintenance» mentionné par Andrew est résolu simplement en utilisant «Update Service Reference» lorsque le contrat de service change. Si cela devient un problème, créez un projet distinct pour contenir toutes les classes de proxy. Il vous suffit ensuite d'utiliser "Update Service Reference" en un seul endroit.
Bien sûr, si le contrat de service ou les contrats associés changent d'une manière incompatible, alors votre code client devra changer. C'est vrai quelle que soit la technique que vous utilisez.
J'ai des classes proxy générées automatiquement dans une bibliothèque séparée faisable?Lorsque vous générez une référence de service, elle génère à la fois la classe proxy et les entrées dans votre fichier app.config. Si vous obtenez les classes proxy sans les entrées du fichier app.config, n'obtenez-vous pas la moitié des avantages? (Rappelez-vous, je préconise que vous faites tout à la main) de toute façon). –
@Andrew: le problème app.config est identique pour chaque composant qui place des éléments dans app.config: vous devez toujours copier les entrées de configuration depuis le fichier app.config de la bibliothèque dans l'application (ou le web) .config de l'application . Toujours. –
Si vous générez le code automatiquement, vous avez un problème de maintenance. Vous devez le régénérer à chaque fois que vous modifiez l'interface ou la configuration du serveur.
Pour cette raison, je ne génère JAMAIS le client à partir de métadonnées exposées.
L'interface doit être définie dans une bibliothèque. Appelons cette bibliothèque MyContractsLib. L'implémentation du service doit être dans un assembly distinct (que j'appelle MyContractsImplementation). Le client devrait aller dans une autre assemblée.
Le client doit ensuite utiliser une ChannelFactory pour créer le service.
var cf = new ChannelFactory<MyContractsLib.MyContract>(this.EndpointName);
MyContractsLib.MyContract serviceProxy = cf.CreateChannel();
Le seul scénario où il est justifié est si le service est développé par un tiers, et vous écrire indépendamment l'application cliente.
Si vous avez le temps et l'inclinaison, voir this presentation va dans ce sens.
alors, que faites-vous lorsque l'interface change et que vous n'utilisez pas "Ajouter une référence de service"? –
@John: Le client et l'implémentation du service doivent lire l'interface à partir du même fichier. Je vais ajouter cela à ma réponse. –
donc vous avez toujours le même problème lorsque la modification est incompatible, et vous devez vous assurer que votre système de construction référence la version correctement mise à jour de l'assembly contenant les contrats, et ce n'est pas différent de maintenir une instance "en cours" du service et en utilisant "Update Service Reference". Dans tous les cas, vous aurez besoin d'une instance déployée du service pour les clients non .NET. –
Voir cette question similaire. Amusant, ce sont les mêmes deux personnes qui répondent. http://stackoverflow.com/questions/3697181/help-debugging-wcf –
Je pense que les deux réponses sont correctes dans différents scénarios. Pour mon scénario particulier et parce que je dois choisir une réponse correcte que je vais utiliser avec le WSDL – dnndeveloper