comment éviter notification massive dans la liaison de données

Question

Je pense qu'il est tout à fait un problème commun dans les scénarios de liaison de données. Qu'est-ce que vous faites habituellement, si vous exécutez une mise à jour de traitement par lots et que vous voulez éviter que les calculs PropertyChanged-dependend / actions / quelles que soient exécutées pour chaque mise à jour unique?

La première chose qui vient généralement à l'esprit, est soit introduit une nouvelle booléenne ou décrochez / accrocher le eventhandler, ...

Ce que je n'aime pas cette approche est:

• ils introduisent une nouvelle complexité (doit être maintenu, ...)
• ils sont source d'erreurs, parce que vous devez vous assurer que les notifications d'un refoulées sont envoyés après

Je me demande si quelqu'un a abordé ce problème déjà d'une manière plus pratique qui est plus facile à manipuler?

tia Martin

Edit: ne pas me missunderstand. Je sais des choses .NET fournit comme RaiseListChangedEvents de BindingList, ... Ils sont tous attaquer le problème du plus / moins de la même façon que je l'ai décrit, mais je suis à la recherche d'une façon différente qui n'a pas les inconvénients énumérés . Peut-être que je suis sur la mauvaise voie, mais je si je donne un essai ici ...

Answer 1

Il n'y a pas un seul one-size-fits-all solution, malheureusement. J'ai appliqué ou vu les solutions suivantes:

1. Il y a deux singals. Un signal est émis lorsque le changement vient d'une action de l'utilisateur, l'autre se déclenche toujours. Cela permet de faire la distinction entre les changements dans l'interface utilisateur et les mises à jour par code.

2. Un booléen pour protéger le code

3. Le cadre de l'événement de la propriété cesse de propager des événements automatiquement lorsqu'une valeur n'a pas vraiment changé.

4. Un procédé de congélation / décongélation sur le signal ou le gestionnaire de signal (à savoir, le cadre entier)

5. Un moyen pour fusionner les signaux en un seul. Vous pouvez faire des mises à jour N et ils sont collectés en signaux M où M <= N. Si vous modifiez la même propriété 100 fois, vous obtenez seulement encore 1 signaux.

6. Queuing de signaux (au lieu d'exécution synchrone). Le code de mise en attente peut alors fusionner les signaux, aussi. Je l'ai utilisé cela avec beaucoup de succès dans une application qui ne dispose pas d'un bouton « Enregistrer ». Toutes les modifications sont enregistrées dans la base de données que vous les faites. Lorsque vous modifiez un texte, les changements sont fusionnés pendant un certain temps (à savoir jusqu'à ce que les précédentes déclarations de mise à jour DB) puis, ils se sont engagés comme un seul changement.

7. Une API pour définir plusieurs valeurs à la fois; seulement un seul signal est émis.

8. Le cadre de signal peut envoyer des signaux à différents niveaux de granularité. Disons que vous avez une personne avec un nom. Lorsque vous modifiez le nom, vous obtenez deux signaux: un pour le changement de nom et d'un « champ d'instance changé ». Donc, si vous vous souciez que « a changé quelque chose », alors vous pouvez accrocher dans l'instance au lieu de tous les champs.

Answer 2

Quelle plate-forme? Le message me fait penser à .NET.

Qu'est-ce que les objets sous-jacents? Par exemple, BindingList<T> comme source vous permet de désactiver les notifications en mettant RaiseListChangedEvents false tout en faisant la mise à jour.

Autre que celui (ou similaire); oui, débranchez la liaison pendant les grandes mises à jour

Answer 3

La route la plus facile à prendre est d'utiliser le composant BindingSource pour votre liaison de données. Au lieu de lier vos contrôles à un objet particulier (ou IList), utilisez cet objet comme DataSource pour le BindingSource, se lient alors les contrôles à l'BindingSource.

La classe BindingSource a des fonctions de SuspendBinding() et ResumeBinding().