approche d'implémentation gui en C# et .NET

Question

Je suis un débutant complet en C# et .NET.
Je suis supposé implémenter une interface graphique pour un processus dorsal en C#.
La conception que je suis obligé de suivre, est d'avoir une grille de données pour afficher les données et que les utilisateurs cliquent sur les lignes, d'autres représentations apparaissent. un graphique des données.
L'interface graphique est gérée par un processus, par ex. ProcessA. Un autre processus, par ex. ProcessB, en cours de traitement et de communication avec les services distants, génère les données qui doivent être affichées dans l'interface graphique.
ProcessB et ProcessA communiquent via une mémoire partagée. C'est à dire. ProcessB met à jour une mémoire partagée et ProcessB lorsqu'il voit une mise à jour (via des bits non valides) met à jour la ligne de données correspondante dans la grille.
Mes questions sont les suivantes:

1. Cette conception est une approche habituelle pour les interfaces graphiques dans les scénarios .NET et de tels? Je demande parce que personnellement je n'aime pas du tout, et je me demandais si j'avais tort de ne pas l'aimer.

2. Y at-il une meilleure conception pour cela, si les exigences sont d'avoir une mise à jour très rapide de l'interface graphique? Par exemple. Devrait ProcessA et ProcessB, être juste un processus? Cette conception est-elle possible en C#? C'est à dire. mettre à jour une grille de données via la mémoire partagée? Parce que, j'ai googlé un peu et il semble que la plupart des tutoriels décrivent qu'une base de données est liée à une source de données (pour l'accès db ou la lecture de fichier xml)

3. En C#, le GUI est complètement mis à jour, c'est-à-dire qu'il est entièrement redessiné à chaque fois une mise à jour à une ligne est faite? Dans ce cas est l'utilisation de bits sales pour savoir quelle partie de la mémoire partagée a été mise à jour afin de mettre à jour la partie correspondante du gui, inutile?

4. Est-il possible de créer un GUI de manière à ce qu'il soit automatiquement mis à jour chaque fois que la mémoire partagée change?

MISE À JOUR: processa et ProcessB sont sur la même machine

Merci

Answer 1

1. en utilisant une interface graphique pour parler à un service WCF est assez fréquent. si c'est ce que vous voulez dire par ProcessA et ProcessB.
2. vous pouvez utiliser un seul processus, mais, vous avez déjà des exigences ...
3. vous pouvez mettre à jour un ArrayList ou quelque chose de similaire, et utiliser alors que source de données
4. non, je ne pense pas
5. bien, vous devez réaliser exactement quand la mise à jour a lieu et créer un événement pour cela. ainsi votre source de données sera mise à jour et ainsi ce que votre grille de données

Answer 2

1. Vous pouvez utiliser EventWaitHandle pour signaler entre les processus, ou l'utilisation WCF. Envoyer des données entre les processus via la mémoire partagée est certainement le moyen le plus rapide, mais WCF est peut-être plus agréable.(Pour vérifier mes vitesse blog post)
2. Si vous pouvez les avoir dans le même processus, il pourrait être une bonne idée, et tout simplement avoir des threads séparés
3. Oui et non. Vous pouvez transmettre les données via la mémoire partagée (à l'aide de fichiers mappés en mémoire), puis vous devez désérialiser les données dans un objet géré qui peut être lié à la grille de données. Ensuite, vous pouvez créer un lecteur/liste sur le fichier mappé en mémoire, qui lit et désérialise un élément à la fois car ils sont liés à la grille.
4. Si vous pouvez détecter les données qui ont changé et mettre à jour uniquement cette partie graphique, c'est une bonne approche. Si vous utilisez des bits non valides dans la mémoire partagée ou si vous exposer une couche de service plus riche dans WCF avec une liaison duplex avec des méthodes de rappel sur les différentes données, il s'agit plutôt d'une option de conception.
5. Avec la signalisation, vous pouvez y parvenir. Le serveur signale quelle partie a changé, le client capte le signal et se met à jour en conséquence.

En général, une approche client/serveur avec une interface et des méthodes définies crée du code plus propre, et vous savez ce que fait chaque partie. Utiliser la mémoire partagée et par exemple la signalisation crée un couplage plus serré, et la lecture du code ne vous dira pas immédiatement ce qui se passe car c'est plus complexe (à mon avis personnel). Cela dit, si la vitesse est de la plus haute importance, et je veux dire la plus grande importance, utilisez la mémoire partagée. Sinon, optez pour la liaison WCF et les tubes nommés, avec un contrat de service duplex. C'est propre et réutilisable.

Answer 3

Par Processus voulez-vous dire fil? Ou parlons-nous d'une interface graphique et d'un service Windows?

Si vous utilisez le filetage, la mémoire partagée est correcte. S'il s'agit de processus réels, la méthode "correcte" consiste à créer un service WCF sur des canaux nommés pour une communication inter-processus sur machine. (Cela facilite également les processus de déplacement de la machine). De cette façon, vous pouvez utiliser une liaison WCF bidirectionnelle (bidirectionnelle) pour mettre à jour votre Gui lorsque les données changent.

Par le son des choses, vous avez besoin de threads plus que de processus. Dans .NET, il existe une classe appelée BackgroundWorker qui est conçue exactement pour ce type de scénario. Le gros problème à résoudre est que si vous devez mettre à jour le gui à partir d'un thread d'arrière-plan, vous devez utiliser le répartiteur de threads Gui. Il peut s'agir d'une petite courbe d'apprentissage, mais je vous recommande fortement d'utiliser WPF et MVVM pour cela. C'est un framework gui qui se prête très bien à la liaison aux données dynamiques.