5 votes

Générer un proxy wcf vs ChannelFactory

Laquelle de ces deux façons d'utiliser le service wcf est la meilleure ? Pourquoi ?

  1. Générer un proxy à partir d'une référence de service
  2. à l'aide de ChannelFactory

ex.

ChannelFactory<IMyContract> factory = new ChannelFactory<IMyContract>();
IMyContract proxy1 = factory.CreateChannel();
proxy1.MyMethod();

Il est un peu ennuyeux d'appeler le service wcf comme donc

IMyContract proxy1 = null; 
try
{
    proxy1 = factory.CreateChannel();
    proxy1.MyMethod();
    ((ICommunicationObject)proxy1).Close();
}
catch
{
   ((ICommunicationObject)proxy1).Abort();
}

Devrions-nous répéter cet extrait pour chaque appel de proxy ? Ou existe-t-il un moyen générique de créer une classe enveloppante pour fermer et interrompre les proxies ?

Est-ce que la classe d'écriture est comme ceci ServiceExecution.Execute(proxy=>proxy.MyMethod()); qui crée un proxy, et le ferme ou l'interrompt bonne façon de procéder ?

3voto

ArsenMkrt Points 24447

Ici est un post MSDN, qui recommande de ne pas utiliser les proxies générés dans .Net 3 parce qu'il crée ChanelFactory à chaque fois, .Net 3.5 ChanelFactory est mis en cache.

Mais personnellement je préfère utiliser ChanelFactory moi-même, le code généré est toujours une plaie même après partials sortir

2voto

Incognito Points 10148

Dans le premier cas, lorsque vous utilisez VS pour ajouter une référence de service, il génère tout le code pour vous, y compris les contrats de service et les contrats de données.

Mais lorsque vous utilisez ChannelFactory vous devez déjà avoir des contrats de service, etc. du côté du client.

2voto

Manfred Points 2625

Je suggère d'utiliser l'approche 1.

J'ai trouvé ceci blog avec un exemple comprenant le code source qui explique également comment gérer correctement la connexion (fermeture, abandon, etc.). Le blog contient également des liens pour plus de détails sur MSDN.

0voto

Benp44 Points 111

La création manuelle des mandataires de service à partir d'un service en cours d'exécution pourrait être une bonne alternative. L'outil svcutil est ce que Visual Studio utilise sous le capot lors de l'ajout d'une référence de service. Grâce à cela, vous pouvez générer la classe proxy dans un emplacement commun, puis la lier à chaque projet dont vous avez besoin, et ainsi obtenir un meilleur contrôle sur vos classes proxy.

Par exemple, pour générer un proxy pour un service appelé Service de test fonctionnant localement sur le port 8000, vous exécuteriez la commande suivante dans l'invite de commande de Visual Studio, générant ainsi une classe proxy TestServiceProxy.cs dans le répertoire proxies.

cd "C:\src\proxies"
svcutil /noLogo /out:TestServiceProxy http://localhost:8000/TestService

Il existe d'autres paramètres utiles pour l'outil, par exemple :

Añadir /n:*,WcfServices.TestService spécifiera un espace de noms pour la classe proxy.

Añadir /config:TestServiceProxy.config et svcutil générera un exemple de fichier de configuration pour l'utilisation de TestService, y compris les points de terminaison, les liaisons, etc.

Añadir /r:"Common.dll" et la classe proxy émise par svcutil n'aura pas de définitions pour les types utilisés par le service, mais définis dans l'assembly Common.dll.

Utilice svcutil /? pour plus d'informations.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X