Best practice winform et service

Bonjour à tous,

J'ai développé un service windows auquel on accède par remoting. J'expose donc une interface contenant mes méthodes.
J'ai ensuite une couche graphique (GUI) en winform qui doit communiquer avec ce service.

Pourriez-vous me dire quelle est la meilleure façon de faire pour utiliser ces méthodes. En effet, je souhaiterais faire une couche me permettant de travailler en asynchrone pour ne pas bloquer le thread GUI le temps de la requête qui peut parfois être longue.

Il y a t'il quelque chose de spécifique à implémenter?

Je pensais à une couche de type backgroundWorker qui enverrait une notification lorsque la tache serait terminée. Mais le problème est de bien implémenter cela. Si vous connaissez l'URL d'un bon tuto, je suis preneur. J'ai cherché mais encore rien trouvé

D'avance merci du coup de main

:salut:

Si tu utilises WCF alors VS te permet de générer un proxy avec des méthodes asynchrones donc pas la peine de passer par un BackgroundWorker :ccool:

Bonjour et merci pour ta réponse.

Malheureusement elle ne m'aide pas beaucoup car je travaille en winform et non en WCF. Mais par contre l'idée du proxy me plait. J'aurais donc dans l'idée de partir sur une metchode qui instancie un thread pour se détacher de l'UI, un worker Thread. Apres je verrais bien un retour sur le thread UI en passant par un event Completed. Un peu comme le background worker.

J'ai des idées, mais je sais pas comment les mettre en place et si elles sont pertinentes. J'ai le soucis de bien faire et c'est pourquoi je recherche le best practice.

Tu utilises quoi comme service ? ASMX ou autre ? dans tous les cas VS te permet d'ajouter une référence de service sur ton projet client donc il est toujours possible d'avoir un proxy généré avec des méthodes asynchrones. Dis-nous qu'est-ce qui te bloque sur ce point ;)

Sinon le fait d'utiliser un BackgroundWorker est aussi une bonne pratique. :ccool:

Il s'agit ici d'un service windows tout à fait classique. ce service fournit des méthodes par remoting. Je peux utiliser une interface que le service mets à disposition au GUI.

Le backgroundworker n'est pas une mauvaise chose en soit mais je le trouve lourd. en effet je vais devoir en instancier autant que j'ai de méthodes à appeler. L'objectif étant de passer par une librairie qui ferait cette gestion. La librairie ferait l'appel au service puis lorsqu'elle recevrait le résultat, elle lancerait une notification au GUI (sur le thread principal) avec en paramètre les données à récupérer. Bien sur cette couche devrait faire une conversion d'objet puisque lorsqu'on récupère des objets par remoting, il s'agit de référence.

Ce qui me bloque ici:
- La façon d'implémenter un système de backgroung working qui me permette de revenir sur le thread principal lorsque la tâche est terminée.

Merci

Citation:

---

Envoyé par FraktaL

Ce qui me bloque ici:
- La façon d'implémenter un système de backgroung working qui me permette de revenir sur le thread principal lorsque la tâche est terminée.

---

C'est ce que fait la classe BackgroundWorker. Il suffit juste de t'abonner à l’évènement RunWorkerCompleted.

Citation:

---

Envoyé par FraktaL

Pourriez-vous me dire quelle est la meilleure façon de faire pour utiliser ces méthodes. En effet, je souhaiterais faire une couche me permettant de travailler en asynchrone pour ne pas bloquer le thread GUI le temps de la requête qui peut parfois être longue.

---

Salut, je préferais faire les appels asynchrones et/ou lancer les threads sur serveur mais ne pas rentrer cette logique dans IHM sauf cas exceptionnel.
Comment appeler des opérations de service WCF de façon asynchrone

Citation:

---

Envoyé par h2s84

Si tu utilises WCF

---

Citation:

---

Envoyé par xp_cmdshell

Comment appeler des opérations de service WCF de façon asynchrone

---

Il a dit qu'il avait utilisé le Remoting; pas la peine de lui répondre sur WCF.

Bonjour

Citation:

---

Envoyé par FraktaL

Malheureusement elle ne m'aide pas beaucoup car je travaille en winform et non en WCF.

---

Il n'y aucune incompatibilité entre les deux (tu dois confondre avec WPF) !

En revanche, il y en a une entre WCF et Remoting.

Pourquoi avoir choisi Remoting qui est une techno dépassée depuis plus de 5 ans ?

Un petit tuto qui m'avait bien aidé http://glarde.developpez.com/dotnet/bgworker/cs/
le backgroundworker faut pas en avoir peur il est super simple à utiliser (je me rappelle avoir utiliser des threads pensant que le backgroundworker n'était pas approprié alors que c'était le contraire).

Merci à tous,

je vais me pencher sur la question du backgroundworker.
Ce que je voulais éviter c'était de faire appel à un contrôle dans la couche asynchrone car j'avais vu une dll s'occupant d'envoyer les requêtes au service et renvoyant le résultat au GUI.

Les remarques concernant le choix du remoting sont pertinentes. J'aurais pu utiliser l'IPC qui est plus souple ou pour être encore plus souple un service WCF.
Mais le service WCF qui offre de nombreux avantages utilise IIS et je ne veux pas dépendre de IIS.

Je souhaiterais une application composée d'un service et d'une interface qui interagit avec ce service.

Si vous avez une idée ou quelque chose à me proposer qui apporte vraiment une plus value par rapport au remoting et qui n'utilise pas IIS je suis intéressé.

Merci encore pour votre aide

Citation:

---

Envoyé par FraktaL

Mais le service WCF qui offre de nombreux avantages utilise IIS et je ne veux pas dépendre de IIS.

---

Faux ! :)
IIS permet effectivement d'héberger des services WCF mais n'importe quelle application peut également le faire.
http://msdn.microsoft.com/en-us/libr...v=vs.100).aspx