Discussion :

[Pilloutou]

Bonjour,

je travaille sur une application qui manipule des code barres.
Mon problème est que cette application utilise selon moi un peu trop les évènements.
L'architecture est la suivante.
J'ai développé une classe qui possède une instance de la classe serialport.
Cette classe est chargé de récupérer le code-barre lue (1er evenement pour la lecture du code-barre) et de le mettre en forme de manière à avoir un string. Une fois mis en forme, un évenement avec en paramètre le code-barre mis en forme est lancé. (Deuxième évenement)
Cet évenement est récupéré par une classe qui va interroger la base de données à partir du code-barre lue pour récupérer le produit associé. Un nouvel évenement (le troisième) est lancé avec en paramètre, le code-barre et le produit associé.
Une autre classe récupère cet évenement pour un traitement (ajout dans une liste de produits) et lance à son tour un évenement (le quatrieme) pour que l'interface graphique puisse être avertie que la liste a été mise à jour et puisse afficher les caractéristiques du dernier produit scanné.

Ce qui me fait 4 evenements, et je serais même tenté d'en rajouter pour d'autre traitement. Il faut que je m'arrête, je me rends compte que je suis un fana des évenements. Je ne sais pas si c'est ainsi qu'il faut faire.
Comment vous y prendriez-vous ?

N'y a-t-il pas un moyen différent de faire la même chose ?

Merci.

[Mehdi Feki]

Ca s'appelle bien la programmation événementielle. Si tu savais combien windows genere d'evenements juste en bougeant la souris ou juste en faisant rien tu ne serais pas trop decu de tes 4 evenements.

[mat.M]

.
Ce qui me fait 4 evenements, et je serais même tenté d'en rajouter pour d'autre traitement. Il faut que je m'arrête, je me rends compte que je suis un fana des évenements. Je ne sais pas si c'est ainsi qu'il faut faire.
Comment vous y prendriez-vous ?
N'y a-t-il pas un moyen différent de faire la même chose ?
Merci.

Il faut faire une programmation multi processus.
Prendre la classe Thread et créer des objets Thread avec au besoin des AutoResetEvent

using System;
using System.Threading;

class Test
{
static void Main()
{
Thread newThread =
new Thread(new ThreadStart(Work.DoWork));
newThread.Start();
}
}

class Work
{
Work() {}

public static void DoWork() {}
}

Sinon tu ne seras pas synchro dans les événements...

Ca s'appelle bien la programmation événementielle. Si tu savais combien windows genere d'evenements juste en bougeant la souris ou juste en faisant rien tu ne serais pas trop decu de tes 4 evenements.

Oui et le problème c'est que des langages qui font abstraction des couches les plus basses masquent totalement ces méchanismes

[Pilloutou]

La réponse est N-tiers

Ah ? C'est ce que j'avais cherché à mettre en place
En fait, j'avais trouvé dans les évenements une solution qui me permettait de répercuter l'évenement de départ initié par le lecteur aux classes des couches supérieures.

premier évènement : oui. viens de l'extérieur, cohérent, c'est de l'interfacage (donc évènementiel)

Oui effectivement, c'est l'évenement envoyé par le lecteur lorsqu'une donnée est présente et réceptionné par la classe LecteurCodeBarre.

Cette classe gère l'ouverture et la fermeture du port série, et surtout récupére les octets de la mémoire tampon et les met sous forme d'un string.

non. c'est juste une classe qui bosse ?

Cette classe est la classe LecteurCodeBarre décrite précédemment.
Je cherchais à faire une telle classe et la rendre réutilisable.

t'as ptet un pti problème d'architecture

Oui, oui c'est que je me demande aussi.

Mais alors comment faire exactement ?

Comme j'expliquais, la classe DetermineCodeBarre est abonné à l'évenement lancé par la classe LecteurCodeBarre.
La classe DetermineCodeBarre comme son nom l'indique, détermine si le code barre lue est celui d'un produit, d'un OF ou autre chose.
Selon, le type associé au code-barre, cette classe effectue le traitement adéquat. Récupérer le produit ou l'OF dans la base de données à l'aide des classes ProduitDAO et OFDAO.

soit tu la fusionnes avec l'autre

Donc tu me conseilles de ne faire qu'une classe entre la classe LecteurCodeBarre et DetermineCodeBarre ?
Dans ce cas, ma classe LecteurCodeBarre ne sert plus et n'est plus réutilisable, non ? Qu'en pensez-vous ?
Et pourtant, tu dois être d'accord(enfin je pense) que le code que j'utilise dans la méthode de la classe LecteurCodeBarre qui met tous les octets reçues sous forme d'une chaîne de caractère doit être réutilisable.

troisième évènement : non. ta classe (code métier) a normallement accès à ta classe d'accès aux données. C'est un appel, pas un évènement.

Cette classe est la classe MaClasseMetier qui va ensuite gérer tout mon process.

MaClasseMetier notifie l'interface utilisateur qu'un changement a eu lieu par un évenement. J'avais lu que c'était une soi-disant bonne solution.

Pour résumer, j'ai les classes suivantes:
LecteurCodeBarre
DetermineCodeBarre
ProduitDAO
OFDAO
MaClasseMetier
MonInterface

Donc globalement, tu me conseilles de faire la chose suivante :
- de ne plus utiliser la classe LecteurCodeBarre.
C'est dommage, je l'aimais bien cette classe.
Mais comment je gère l'ouverture et la fermeture ?

- que DetermineCodeBarre récupère le code-barre et le mette sous forme d'une chaîne de caractères en appelant une méthode static.
Mais je ne trouve pas ça réutilisable, qu'en penses-tu ?

- que MaClasseMetier accède à ma classe DetermineCodeBarre pour récupérer le produit ou l'OF mais comment sait-elle qu'il y a un nouveau produit ou un nouveau OF ?

Et sinon, oui mon Interface n'est pas threadé, puisque l'évenement émis par la classe SerialPort est automatiquement mis dans un autre thread.

Si tu avais un exemple, ce serait cool, parce que dans le principe je comprends bien, mais je ne vois pas trop comment faire.

Il faut faire une programmation multi processus.
Prendre la classe Thread et créer des objets Thread avec au besoin des AutoResetEvent
Sinon tu ne seras pas synchro dans les événements...

Ah ? Et pourtant il me semblait que les évenements étaient synchro.
Pour info, j'ai essayé d'utiliser des évenements asynchrones.

Je vais étudier cela. Merci.

Merci pour votre aide.

[Mose]

Donc tu me conseilles de ne faire qu'une classe entre la classe LecteurCodeBarre et DetermineCodeBarre ?

+1 pour la réponse de Maniak
DetermineCodeBarre est un objet, mais son nom commence par un verbe.
C'est pas plutôt une méthode qu'il te faudrait ?

Sinon, pour la réutilisabilité, oui, ça pose problème si tu fusionnes une classe réutilisable d'une autre.
Ce qu'il faut faire, selon mon expérience et mes cours de POO, c'est faire un 'super objet'

Ex :
* LecteurCodeBarre : réutilisable, commun à plusieurs applis
* LecteurCodeBarrePourMachin : non réutilisable, spécifique à l'appli machin

-> selon ta conception, soit ton lecteur spécifique hérite de ton lecteur générique, soit il le wrap (il en contient un dans un champ privé)
-> le code de 'DetermineLecteur...' tu le colles alors dans ton lecteur spécifique.

Avantage de l'héritage : quand tu as une opération réutilisable que tu veux appliquer sur tous tes lecteurs, par polymorphisme tu peux le faire sur ton lecteur spécifique.

Pour le détail : on voit ça par MP, oki ?

[Maniak]

Je ne sais pas si c'est ainsi qu'il faut faire.

Ce qu'il faut faire, c'est quelque chose de propre, simple, compréhensible. Si faire des évènements permet d'y arriver, où est le problème ?

N'y a-t-il pas un moyen différent de faire la même chose ?

Probablement. Y a-t-il un problème avec la manière dont tu l'as fait jusque-là ? Ça devient trop compliqué ? Pas facile à suivre ?
Si oui, peut-être qu'il faut essayer de simplifier. Si non, pourquoi changer ?

[Pilloutou]

J'ai aussi un 5eme évenement qui lui par contre m'embête et me fait dire que ça devient un peu compliqué tout ces évenements.
Un code-barre est scanné.
La classe récupérant les code-barres génère un évenement pour transmettre ce code-barre sous forme d'une string.
Il est attrapé par la classe qui va dire si ce code-barre est celui d'un produit ou la référence d'un OF. Si c'est celui d'un produit, cette classe va interroger la base de données pour savoir à quel produit correspond ce produit.
Si c'est celui d'un OF, la classe va transmettre cet évenement à la classe principale de ma dll qui va à son tour transmettre ce code-barre à l'interface utilisateur en l'occurence une winforms pour que l'utilisateur puisse recevoir le code-barre de l'OF scanné et créer une nouvelle mise en production à partir de la référence de cet OF.

Là je pense que vous êtes d'accord avec moi pour dire que ça devient un peu compliqué.

Vous allez certainement me dire, mais dans ce cas, pourquoi l'interface utilisateur ne s'abonne pas directement à l'évenement de la classe gérant les code-barres. Ca ce n'est pas trop possible car comme je le disais le code-barre est celui d'un produit ou celui d'un OF. Tout dépend, la forme qu'il a. Et c'est le rôle d'une classe de le déterminer.

Vous allez ensuite me dire, mais pourquoi l'interface utilisateur ne s'abonne pas directement à l'évenement que lance la classe qui détermine si c'est un produit ou un OF.
Et là je réponds qu'en fait, j'avais choisi de ne pas mettre cette classe public pour diminuer le couplage entre ma dll et mon interface utilisateur.
Je voulais que mon interface utilisateur n'accède à ma dll que via la classe principale de ma dll.
Mais tout se discute.

[Royd938]

Hello,

Pour ma part, je concois les choses de la manière suivante. Les événements sont à utiliser pour signaler une action à un moment donné, moment auquel tu ne pouvais pas spécialement t'attendre. Je veux dire par là que le seul évènement correct selon moi est le scan du code barre. Mais après cela, c'est le traitement logique à suivre => conversion en string -> recherche base de donnée...etc. Tu peux tout simplement passé des objets et pas spécialement créer des événements.

Enfin voilà, c'est ma vision...

Bonne chance

[fregolo52]

Si tu veux éviter les événements, tu peux tenter les design pattern observer et MVC, en utilisant des interface.
Mais si tu maîtrises bien les événements garde cette méthode.

[Pilloutou]

Pour ma part, je concois les choses de la manière suivante. Les événements sont à utiliser pour signaler une action à un moment donné

Je suis assez d'accord avec ça.

Je veux dire par là que le seul évènement correct selon moi est le scan du code barre.

Je comprends bien.
Comme je le disais j'ai une classe qui récupère le code-barre. Une fois mis en forme sous forme d'une string, elle émet un évenement avec le code-barre sous forme d'une string. Ainsi ça permettait selon moi de faire une classe autonome qui réceptionne le code-barre et le met en forme. A moins que cette classe n'est pas d'interêt... mais elle ne peut pas appeler un autre objet de ma dll.
Ou alors l'autre solution consiterait à utiliser une classe centrale de ma dll de réceptionner le code-barre et de faire ce qu'elle veut. J'avais pensé à cette solution, mais dans ce cas pour toutes autres application que je développerai avec une lecture de code-barre, je serai obligé de copier/coller la fonction de mise en forme du code-barre réceptionné. Voilà pourquoi j'avais évité d'utiliser cette solution.
A moins que je m'y prenne mal .

[Maniak]

La classe récupérant les code-barres génère un évenement pour transmettre ce code-barre sous forme d'une string.

Blip.
C'est pas un évènement que tu décris là. C'est une méthode.
Les évènements c'est "hep y a eu un scan. ça intéresse quelqu'un ?". C'est pas pour faire du passage de paramètres :)

[Pilloutou]

C'est pas un évènement que tu décris là. C'est une méthode.
Les évènements c'est "hep y a eu un scan. ça intéresse quelqu'un ?". C'est pas pour faire du passage de paramètres

Oui oui c'est juste. Je ne sais pas ce qui m'a pris, j'ai un peu dévié, un moment de faiblesse certainement.

Mais comme je le disais, ma démarche a été de vouloir concevoir une classe LecteurCodeBarre autonome et réutilisable. Et pour cela, je me suis dit que je ne devais pas injecter de dépendance supplémentaire en appelant depuis cette classe, qui je le rappelle reçoit le code-barre la première, la méthode d'un objet de ma couche métier pour transmettre le code-barre.

Et pour le reste, l'idée venait de la lecture de ce document
http://www.codeproject.com/csharp/mo...controller.asp,
l'utilisation des évenements pour informer la vue d'un changement de la couche métier.
Comme je disais, j'avais trouvé dans les évenements une solution qui me permettait de répercuter l'évenement de départ initié par le lecteur aux classes des couches supérieures.

J'ai essayé la solution de Mat.m, c'est pas trop évident à intégrer mais faut que je persévère.

Merci.