Comment concevoir une grille haute performance avec VS 2005 (en particulier C#)

Question

Je dois créer une grille de données Winforms haute performance en utilisant Visual Studio 2005, et je ne sais pas par où commencer. J'ai construit beaucoup d'applications de grille de données, mais aucune d'elles n'était très bonne lorsque les données étaient constamment rafraîchissantes.

La grille va être d'environ 100 lignes par 40 colonnes, et chaque cellule de la grille va mettre à jour entre 1 et 2 fois par seconde (certaines cellules peut-être plus). Pour moi, c'est le plus grand inconvénient de la grille de données prête à l'emploi, la repeindre n'est pas très efficace.

mises en garde Couple

1) Aucun fournisseur tiers. Cette grille est l'épine dorsale de toutes nos applications, alors que XCeed ou Syncfusion ou quoi que ce soit pourrait nous permettre de fonctionner plus rapidement, nous nous heurterions à ses limites et serions arrosés. Je préférerais faire le travail supplémentaire à l'avant, et avoir une grille qui fait exactement ce dont nous avons besoin.

2) J'ai accès à Visual Studio 2008, donc s'il est préférable de commencer en 2008, alors je peux le faire. Si c'est un tossup, je voudrais rester avec 2005.

Alors, quelle est la meilleure approche ici?

Answer 1

Nous utilisons le contrôle de grille Syncfusion et d'après ce que j'ai vu, c'est assez flexible si vous prenez le temps de le modifier. Je ne travaille pas avec le contrôle moi-même, un de mes collègues fait tout le travail de la grille, mais nous avons assez bien étendu à nos besoins, y compris la peinture personnalisée. Je sais que ce n'est pas exactement répondre à votre question, mais écrire un contrôle comme celui-ci à partir de zéro va toujours être beaucoup plus compliqué que prévu, peu importe vos anticipations. Comme il sera constamment mis à jour je suppose que ça va être databound qui sera une corvée en soi, surtout pour que ce soit très performant. Ensuite, il y a le débogage.

Answer 2

Je recommanderais l'approche suivante si vous avez plusieurs cellules qui sont mises à jour à des débits différents. Plutôt que d'essayer d'invalider chaque cellule chaque fois que la valeur change, il vaut mieux limiter le taux de rafraîchissement. Avoir une minuterie qui se déclenche à un taux prédéfini, par exemple 4 fois par seconde, puis chaque fois qu'elle se déclenche, vous repeignez les cellules qui ont changé depuis la dernière fois. Vous pouvez ensuite ajuster le taux de mise à jour afin de trouver le meilleur compromis entre performance et facilité d'utilisation avec quelques tests simples.

Ceci a l'avantage de ne pas essayer de mettre à jour trop souvent et de tuer ainsi les performances de votre CPU. Il enchaîne les changements entre chaque cycle d'actualisation et donc deux changements rapides à une valeur qui se produisent à des fractions de seconde ne provoquent pas deux rafraîchissements lorsque seule la dernière valeur vaut vraiment la peine d'être dessinée.

Notez que ce dessin différé ne s'applique qu'aux mises à jour rapides et ne s'applique pas au dessin général, par exemple lorsque l'utilisateur déplace la barre de défilement. Dans ce cas, vous devez dessiner aussi vite que les événements de défilement se produisent pour donner une belle expérience. Essayez la grille à partir de DevExpress ou de ComponentOne.

Answer 3

Je sais par expérience que les grilles intégrées ne seront jamais assez rapides pour les applications les plus insignifiantes.

Answer 4

Je prévois de construire un contrôle de grille pour faire la même chose que le temps de passage, mais je n'ai toujours pas le temps. La plupart des contrôles de grille commerciaux ont une grande empreinte de la mémoire et la mise à jour est généralement un problème.

Mes conseils seraient (si vous allez contrôle personnalisé) 1. Étendre un contrôle (pas UserControl ou quelque chose de similaire). Cela vous donnera de la vitesse, sans perdre beaucoup. 2. Dans mon cas, je ciblais la grille pour contenir plus de données. Dites un million de lignes avec 20 à 100 colonnes impaires. Dans de tels scénarios, il est généralement plus logique de dessiner vous-même. N'essayez pas de représenter chaque cellule par un certain contrôle (comme dire Label, TextBox, etc.). Ils mangent beaucoup de ressources (poignées de fenêtre, mémoire, etc.). 3. Allez MVC. L'idée est simple: à tout moment, vous pouvez afficher une quantité limitée de données, en raison de limitations de taille d'écran, limitation des yeux humains, etc Donc, votre fenêtre est très petite, même si vous avez gazillion lignes et colonnes et le le nombre de mises à jour que vous avez à faire n'est pas plus de 5 par seconde pour être utile à lire même si les données derrière l'identifiant de la grille sont mises à jour gazillion fois par seconde. Souvenez-vous également que même si le texte/l'image à afficher par cellule est énorme, l'utilisateur est toujours limité par la taille de la cellule. Les styles de cache (mot générique pour représenter les textes, les polices, les couleurs, etc.), aident également dans un tel scénario en fonction du nombre d'entre eux que vous utiliserez dans votre grille.

Il y aura beaucoup plus de travail pour obtenir un dessin de base (surlignages, grille, limites, bordures, etc.) pour obtenir divers effets.

Je ne me souviens pas exactement, mais il y avait une grille C# .net sur sourceforge, qui peut vous donner une bonne idée de la façon de commencer. Cette grille offre 2 options, VirtualGrid où les données du modèle ne sont pas tenues par la grille, ce qui la rend très légère, et une grille réelle (traditionnelle) où le stockage des données est détenu par la grille elle-même (en créant un doublon, mais dépend de l'application).)

pour un super-agile (en termes de mises à jour), il est peut-être préférable d'avoir un "VirtualGrid"

juste mes pensées