Salut a tous,
 
Je suis encore "debutant" en prog et actuellement je suis sur une application multi-threads et j'aimerais savoir en theorie s'il est possible de separer completement l'interface graphique du moteur.
Voila en fait ce que j'aimerais faire (mais je sais pas si c'est possible et comment le faire) :
J'aimerais creer un espace d'echange en memoire qui gere les acces concurrents et qui serait alimenter par le moteur en donnees et l'interface graphique y piocherait les donnees dont elle a besoin en plus d'y referencer les actions utilisateurs qui pourraient influencer le comportement du moteur.
Est-ce que cela est possible? si oui qu'elle est la technologie a utiliser?
 
Merci d'avance.
 
Razor.
 
PS: Je code en C# pour ceux que ca pourrait aider...

Il est tout à fait possible de séparer la GUI et le "core". C'est d'ailleurs une des grandes forces de .NET, grâce notamment à l'utilisation des events et des composants.
 
En quelques mots, tu crées un assembly de type "Class Library" qui contiens la logique de ton programme. Il contiendra (grossièrement) une classe utilisée par la GUI, qui fournira un certain nombre d'évenements, propriétés et méthodes.
Ensuite, ta GUI viendra s'enregistrer sur ces évènements (l'opérateur += sur les events).
 
Tu as cependant deux problèmes en un ici. La séparation GUI/Logique et le threading. En ce qui concerne le threading, les même règles que celle que l'on pouvait trouver avec Win32 s'appliquent. Autrement dit, tu n'as pas le droit de mettre à jour la GUI depuis une thread de ton core, par exemple. Tout du moins, pas directement.
 
Tu as besoin d'utiliser les namespaces suivants : System.Threading pour les threads, mutexes et autre monitors et System.Collection pour ton "espace d'échange". Attention à la synchronisation des collections qui doit être effectuée soit par l'intermédiaire du mot clé "lock", soit par l'intermédiaire de collections synchronisées. (e.g. ArrayList.Synchronized)
 
C'est un sujet assez vaste
 
--
Jay
{Epitech.}
http://www.labtech.epitech.net/blogs

C'est un peu casse-tête, ton histoire multithread...
 
Personnellement, pour ton problème, je tenterais plutôt une conception mutli-couche : de cette façon tu peux séparer l'interface graphique, la logique et les données, tout en bénéficiant d'un traitement asynchrone sur la couche métier, locale ou non.
 
Mais il faut utiliser un bon paquet de technologies pour faire ça, et c'est pas forcément l'architecture de choix pour un débutant.
 
Sinon, à partir d'une application simple, il est possible de démarrer des fonctions "lentes" dans un thread séparé pour pouvoir conserver la réactivité de l'interface graphique, mais ça c'est autre chose.
 
Il y quelques articles intéressants que tu devrais consulter sur MSDN. Cela te permettrait déjà d'y voir plus clair.
 
// EDIT: grilled
// EDIT: il débute : mieux vaut avoir un aperçu général des solutions disponibles plutôt que de coder à toute pompe... C'est mon avis.

 
Tout à fait Le problème pour les débutant dans ce genre de chose est justement de mettre la main sur ces technologies, considérant leur nombre. Un peu d'aide pour avoir quelques bases et la possibilité de savoir plus où moins où chercher après cela n'est pas inutile
 
Mais nous somme d'accord : Un bon code est un code réfléchi avant son écriture... A condition de savoir où l'on va
 
--
Jay
{Epitech.}
http://www.labtech.epitech.net/blogs

Merci bcp les gars j'ai de quoi occuper mes prochaines semaines en recherche et analyse.
J'apprecie bcp le partage de votre experience!
Reste a trouver maintenant quelle techno va etre la plus appropriee a ce que je veux faire... Une bonne serie de Dummies applications, c'est partie!

Bon apres reflexion, Jaylee je crois que j'ai a peu pres compris le raisonnement de la solution que tu proposes, meme si je suis pas sur que l'application pratique de ce raisonnement soit du gateau... Par contre Yttrium, j'avoue que je suis pas tres bien ce que tu entends par "couche" ...  
Ca donnerait une couche graphique, une couche logique et une couche donnees?
Comment se caracterisent ces couches reellement? Ce sont des classes independantes du contexte? ou bien autre chose de plus obscurs a mes yeux! ;P