ChannelFactory WCF vs génération proxy

Question

Je me demandais dans quelles circonstances vous préférez générer un proxy d’un service WCF lorsque vous pouvez simplement appeler les appels à l’aide de ChannelFactory ?

De cette façon vous ne dois générer un proxy et s’inquiètent de régénérer un proxy lorsque le serveur est mis à jour ?

Merci

Answer 1

Il y a 3 façons de base pour créer un WCF client:

1. Laisser Visual Studio générer votre proxy. Cette auto génère le code qui se connecte au service, en lisant le fichier WSDL. Si la modification du service pour toute raison, vous avez à le régénérer. Le gros avantage de cette solution est qu'elle est facile à mettre en place - VS a un assistant et tout est automatique. L'inconvénient est que vous êtes en s'appuyant sur VS à faire tout le travail dur pour vous, et si vous perdez le contrôle.

2. Utiliser ChannelFactory avec une interface connue. Cela dépend de vous d'avoir les interfaces locales qui décrivent le service (contrat de service). Le gros avantage, c'est que peut gérer le changement beaucoup plus facilement, vous devez recompiler et de fixer des changements, mais maintenant vous n'êtes pas la régénération de code, vous faites référence à la nouvelle interface. Généralement ce qui est utilisé lorsque vous contrôler à la fois le serveur et le client que les deux peuvent être beaucoup plus facilement raillé pour les tests unitaires. Cependant, les interfaces peuvent être écrites pour n'importe quel service, même dans le REPOS ceux - jetez un oeil à cette API Twitter.

3. Écrivez votre propre proxy - c'est assez facile à faire, surtout pour le REPOS de services, à l'aide de l' HttpClient ou WebClient. Cela vous donne les plus beaux grains de contrôle, mais au prix de beaucoup de service de l'API étant dans les chaînes. Par exemple: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - si les détails de l'API changer, vous ne rencontrerez pas une erreur jusqu'à ce que l'exécution.

Personnellement, je n'ai jamais aimé l'option 1 - en s'appuyant sur la génération automatique de code est illisible et perd trop de contrôle. De Plus il crée souvent de la sérialisation des questions - je me retrouve avec deux classes identiques (l'une dans le code du serveur, une auto généré) qui peut être tided mais une douleur.

Option 2 doit être parfait, mais les Canaux sont un peu trop limitant, par exemple, ils perdent complètement le contenu d'erreurs HTTP. Qui a dit que les interfaces qui décrivent le service est beaucoup plus facile à code avec et à entretenir.

Answer 2

J'utilise ChannelFactory avec MetadataResolver.Résoudre méthode. La configuration du Client est une peine, si je reçois mon ServiceEndpoint à partir du serveur.

Lorsque vous utilisez ChannelFactory(T), T est le contrat original que vous pouvez obtenir à partir d'une référence dans votre projet ou un contrat d'instance. Dans certains projets, j'ai le code généré à partir d'un Service de Référence, parce que je ne pouvais pas ajouter une référence au contrat dll. Vous pouvez même générer un asynch contrat avec le service de référence et de l'utilisation de ce contrat d'interface avec ChannelFactory.

Le point principal de l'utilisation ChannelFactory pour moi a été de se débarrasser de la WCF client les informations de configuration. Dans l'exemple de code ci-dessous, vous pouvez voir comment réaliser un WCF client sans config.

Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()

Dans mon projet final, la availableBindings sont vérifiées pour utiliser net.tcp ou net.pipe si disponible. De cette façon, je peux utiliser le meilleur de liaison disponibles pour répondre à mes besoins. J'ai seulement compter sur le fait que d'un point de terminaison de métadonnées existent pas sur le serveur.

J'espère que cette aide

BTW, c'est fait à l'aide .NET 3.5. Cependant, il fonctionne également avec la version 4.0.

Answer 3

Eh bien, pour pouvoir utiliser vous devez être prêt à partager les assemblys de contrat entre le service et le client. Si c’est OK avec vous puis vous pouvez gagner du temps.

Answer 4

Le proxy va construire les fonctions async pour qui est peu agréable.

Answer 5

Ma réponse est une sorte de résumé des réponses de Keith et Du lièvre Andrew .

Si vous ne contrôlez pas le serveur, mais ont seulement WSDL/URL-générer le proxy à l’aide de Visual Studio ou svcutil. (Notez que Visual Studio a parfois échoué, lorsque svcutil fonctionne mieux).

Lorsque vous contrôlez le serveur et le client, partager les interfaces/contrats et appelez ChannelFactory
.