Discussion :

[ElTchoupi]

Bonjour,

=> Je cherche une manière modulaire d'intégrer un système de commandes (avec retour d'informations) dans une appli n-tiers.

Je suis souvent amené à developper des applis (lourdes) dont certains traitements, demandés par l'utilisateur (donc par le UI), sont longs en BusinessLayer (BL).
Evidemment, je veux pouvoir montrer à l'utilisateur que sa commande a été prise en compte, qu'elle "avance" et quel est son résultat.
Je ne veux donc pas que le lancement d'une de ces commandes "freeze" le reste de l'appli: on va utiliser des threads séparés !

Voilà ce que j'utilise actuellement comme solution:

Le BusinessControler (BC) est le seul point d'accès "par le haut" de ma BL: il a, lui, accès au BusinessManager qui connait tous les traitements métiers.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
WaitCallback myCallBack = new WaitCallback(myTask.DoJob);
ThreadPool.QueueUserWorkItem(myCallBack, aRequestParams);

Le "myTask" que vous voyez et qui explose la méthode à exéctuer est une encapsulation de ce qu'il me faut pour "garder le contact" avec ma commande: des events de progression/cancel/error/fin, un ID, une "Designation"(enum), etc...
Pour que ce soit utilisable de façon transparente, tout cela est mis à dispo par un interface:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public interface ITask
{
	TaskDesignation Designation { get; }
	string AssignedId { get; }
 
	event TaskCompletedEventHandler TaskCompleted;
	event TaskProgressChangedEventHandler TaskProgressChanged;
	event TaskCanceledEventHandler TaskCanceled;
	event TaskErrorEventHandler TaskError;
 
	void DoJob(object aJobParams);
	bool CancelTask(TaskCompletedEventHandler aTaskCompleted);
}

Lorsque je fais une demande de Task, je passe en parametres directement les EventHandlers qu'il me faudra ainsi qu'une TaskDescription.

Ce que je n'aime pas, c'est que ce système m'oblige donc à exposer mes commandes dans des classes séparées, implémentant "ITask", .. qui ne font qu'appeller des méthodes de mon BusinessManager.
J'ai donc une couche de séparation seulement pour ces "Tasks" et ... je ne peux pas appeler directement une méthode de mon BM en précisant que je veux une execution asynchrone.

Je voudrais le beurre, l'argent du beurre et si possible un peu plus:
- Pouvoir passer directement mes méthodes métier à un "répartiteur de Task" en quand même récupérer des infos d'avancement/cancel/error et fin.
- Avoir tout ça dans un module séparable d'un projet pour le réutiliser dans un autre

Pour l'instant, j'ai pensé à transformer mon ITask en "marqueur" de task, qui propose les mêmes infos mais serait passé en argument à une méthode de mon BM quand je décrète qu'elle doit pouvoir informer de son avancement, complete/echec, etc...
Les autres méthodes de mon BM que je voudrais appeller depuis mon BC ne pourraient juste pas informer de quoi que ce soit vu qu'elles ne pourraient pas recevoir ce "marqueur".

J'ai probablement oublié plein de détails mais je reste à dispo pour répondre ASAP...

=> Est-ce que mon idée est délirante ou pas ?
=> Est-ce que vous auriez d'autres idées ?
=> Est-ce qu'il existe de best-practices sur ce type de problématique ? (je précise que j'ai cherché mais rien trouvé d'aussi "complet").

Merci d'avance de votre aide !

[binoo]

Salut,

Je suis souvent amené à developper des applis (lourdes) dont certains traitements, demandés par l'utilisateur (donc par le UI), sont longs en BusinessLayer (BL).
Evidemment, je veux pouvoir montrer à l'utilisateur que sa commande a été prise en compte, qu'elle "avance" et quel est son résultat.
Je ne veux donc pas que le lancement d'une de ces commandes "freeze" le reste de l'appli: on va utiliser des threads séparés !

Ce besoin m'amènerai à utiliser le BackgroundWorker. As-tu déjà vu/utilisé cette classe ? Est-tu limité par ce qu'elle met à disposition (pour tes besoins) ?

[ElTchoupi]

Bonjour Binoo,

Lorsque j'avais mis le système que j'ai décrit en place, j'avais rapidement écarté les BackgroundWorkers, me semble-t-il parcequ'ils ne permettent pas de retour d'information "en live": état de progression, retour de résultat, etc...

Me trompe-je ?

(Je retourne lire l'article que tu indiques, pour être sûr...)

[ElTchoupi]

Me trompe-je ?

(Je retourne lire l'article que tu indiques, pour être sûr...)

Bon, je suis venu, j'ai relu... et je suis vaincu :/

Il semblerait que ces BW suffisent.
Pourquoi est-ce que je me souviens qu'ils étaient trop limités ?


Merci pour ta réponse qui fait fondre ma grande question en rappel pour débutant...!
Je teste ça avant de passer le thread en résolu

[binoo]

Si t'as des question sur la mise en place des BackgroundWorker, n'hésites pas

La doc msdn n'est pas toujours très explicite. Il y a ce lien sur le forum :
http://glarde.developpez.com/dotnet/bgworker/cs/

[ElTchoupi]

Si t'as des question sur la mise en place des BackgroundWorker, n'hésites pas

Une seule reste, en confirmation:
Si j'ai bien compris, les BW sont ce que je voyais comme solution possible: les méthodes qu'on peut utiliser recoivent un "marqueur" de BackgroundWorker qui permet de communiquer avec le reste du monde (et surtout que ce dernier reste informé!).

Sauf qu'évidemment:
- D'une c'est déjà implémenté donc je vais pas le refaire..
- De deux c'est Microsoft qui l'a implémenté donc c'est (à piori) mieux fait que par moi !

Merci pour tes réponses...