Discussion :

[Jean-Philippe André]

Parfois, je me dis que j'étais tellement mieux en VBA, mais les mechants clients qui croient qu'on sait pas faire veulent du .Net

J'ai tellement abhorré les cours de POO que j'ai peur de faire des erreurs dans mes choix et mon vocabulaire pour exprimer mes idées .

Ma problématique :
Je souhaiterai mettre en place 2 éléments en .Net:
-Un outil qui tournerait en continu sur un poste, dans lequel un objet récupère en continu des informations boursieres (cours d'un actif ou carnet d'ordres par exemple) - je nomme cette objet A (ca sera une classe si je ne me trompe pas).
- une dll développée en .net aussi, utilisée par les utilisateurs finaux, dans laquelle on peut faire appel à cette classe A.

Ma question :
Est-il bien possible de répliquer en continu l'information disponible dans mon outil connecté au marché en passant par la DLL ?

[Er3van]

J'ai peut-être mal compris, mais pour moi il faudrait séparé la fonction du support.

Ta fonction c'est la récupération de données boursières (par exemple dans une base de données quelconque). Cela serait une "bibliothèque de classes" au sens projet .net (Visual Studio).

Ton support c'est ton applicatif qui tourne en continu sur ta machine (par exemple, un service Windows) et qui appelle lui-même cette classe.

C'est bien ça que tu veux ?

[Jean-Philippe André]

Dans l'idée, je m'imagine les interactions dans l'image en PJ.

Est-ce bien ce que tu me demandes ?

[Nathanael Marchand]

Je suggère un service windows qui tourne en tache de fond et qui va chercher les données. Ce service expose un service WCF avec lequel ta GUI peut dialoguer.

[Bluedeep]

Dans l'idée, je m'imagine les interactions dans l'image en PJ.

Est-ce bien ce que tu me demandes ?

Le choix des solutions techniques à mettre en oeuvre ici dépend entre autre :

- du niveau de performance requis (temps de transit contraint, mais de quel ordre ? plutot "milliseconde" ou "seconde" ?)

- de l'emplacement physique de tes "briques" : toutes sur la même station ou partageable entre stations ?

[Er3van]

Je ne vois pas trop comment tes utilisateurs finaux vont utiliser la DLL !

Tu as un autre applicatif au milieu j'imagine ?
Voici ce que j'avais/j'ai compris :

Ton utilisateur, via un outil .net qui utilise ta DLL, se connecte à ta base de données toutes les n secondes.
Ce n'est pas ton outil .net qui sera accédé par ta DLL, mais bien ta source de données.

Sinon, voici une autre hypothèse :

Ton "outil" .net est un service Web (ou WebService :p) qui récupère sur demande les données dans ta base.
L'outil de l'utilisateur final appellerait ce WebService toutes les n secondes.

Par contre, il n'y a pas dans ce cas de "Continuous Data()", le WebService agit "à la demande" uniquement.

[Jean-Philippe André]

Hum, des questions sur les pistes proposées :
- le service WCF en question, il est developpé dans mon outil ou en dehors ?
- côté performance, c'est des données boursieres, donc de l'instantané (<1 sec me parait sur, de là à dire 250 ou 500 millisecondes )
- l'outil tourne sur un poste, les autres sont sur le réseau (meme si physiquement les machines sont à 2m l'un de l'autre)
- pour la classe, en fait j'aurais une classe unique d'entrée (masterClasse), dont les autres classes liées aux data providers seront dérivées (j'utilise en principe soit des API soit des fonctions depuis Excel)


Confortez moi dans un premier temps que c'est bien techniquement faisable, j'aurais le temps d'évacuer la |[{|#[| de pression que je me mets en voyant le verre d'eau...

[Er3van]

EDIT : Oui, c'est faisable sans problème. Le truc, c'est qu'il y a plusieurs façons de procéder qui sont assez différentes dans l'approche et dans le fonctionnement. Le choix se fera en fonction de tes besoins.

Sinon je pense à une autre option, vous me direz ce que vous en pensez:

Au lieu d'un WebService, c'est bien un Service Windows.

Celui-ci écrit toutes les 500ms dans une file MQ (publish).
Les différents clients seraient alors en mode "subscribe" et consommeraient les messages "mise à jour des données".

Par contre, autant je me sers des technos MQ IBM (MQSeries) et je sais que ça se fait très bien (via un Broker), autant j'ignore si ça existe en MSMQ.
S'il faut utiliser les MQSeries, la licence va te coûter un bras...
EDIT : Bon apparemment ça se fait aussi avec MSMQ => voir chapitre "Publish and subscribe"

En tout cas, ça répondrait à mon avis parfaitement à ton besoin (et même mieux qu'un WebService).

[Jean-Philippe André]

Hum,

le truc c'est qu'en gros l'interfaçage data provider/utilisateur, il existe déjà en VBA dans la boite. Ca coûte pas un radis, donc moi j'etais parti sur un projet pour quelques feuilles de radis max (achat d'une version non express de visual studio par exemple)

J'ai réussi à adapter le code VBA en Vb.net, passant d'un module de classe vba à une Class .net, mais la où psychologiquement je doute, c'est le fait de séparer l'outil avec mon interface graphique et le fait de passer par une librairie de fonctions. Toute la partie récupération de données stockées dans une base alimentée à des moments clés, ca je sais déjà faire (connection via ODBC), mais c'est vraiment la partie librairie avec finalement une objet virtuel qui se connecte sur mon objet réel qui fait tache

[Jean-Philippe André]

Je prends la piste du WCF, qui me semble la chose la plus simple à appréhender en l'état actuel de mon océan d'ignorance

[Jean-Philippe André]

J'utilise le tutoriel de Webman :
http://webman.developpez.com/articles/dotnet/wcf/intro/
mais j'ai l'impression que certaines étapes sont "trop vite" franchies dans le chapitre 3.

Trop d'évidence sont passées sous ellypses, et j'aimerai pouvoir mettre en place cette histoire de client

[BenoitM]

J'utilise le tutoriel de Webman :
http://webman.developpez.com/articles/dotnet/wcf/intro/
mais j'ai l'impression que certaines étapes sont "trop vite" franchies dans le chapitre 3.

Trop d'évidence sont passées sous ellypses, et j'aimerai pouvoir mettre en place cette histoire de client

Tu peux télécharger la solution http://webman.developpez.com/article...o/IntroWcf.zip

[Jean-Philippe André]

oh mon dieu

[Jean-Philippe André]

Il est vivant !!!

Bon ben maintenant je dépiotte ce programme qui fonctionne pour tacher de l'adapter à mon cas.


Pouvez vous me dire si ici on aurait (a) traité le lien entre le tool et la librairie ou le tool et la plateforme boursiere ?

[Jean-Philippe André]

Ok,
j'avance bien sur les blocs et ce que je vais devoir y implémenter.

Toujours en partant de l'exemple téléchargé, je constate que la mise à jour du montant se fait seulement lors de l'appel du service, ce que je comprends ici.

Existe-t-il un "type de service" ou une méthode qui fonctionnerait avec une méthode :
- un abonnement en début de journée (createchannel())
- la valeur monitorée constamment sans envoi toutes les x millisecondes d'une demande
- fin de l'abonnement en fin de journée (myChannelFactory.Close() n'apparait d'ailleur pas dans l'evenement du clic bouton "convert")

[BenoitM]

Il faut creer une task ou backgroundworker ou un thread

[Jean-Philippe André]

Je prends backgroundworker pour avancer merci

[BenoitM]

Il y a aussi le Timer

J'ai oublié qu'il y avait 2 version (une normal et une pour les winform )

[Jean-Philippe André]

ah ok

un type d'objet qui permettrait un flux continu en input ?

[BenoitM]

un type d'objet qui permettrait un flux continu en input ?

euh pas compris