In general, my preference is to base the design on polling at fairly low frequency, but then to use events to trigger early scans.

The good thing about events is responsiveness.

There are a few bad things about them:

- They can happen more often than you want, as for example there may be 10 events in a row, early ones being overridden by later ones, and the program gets jerked around trying to track every little change. This is the "short leash" problem. If there are two bodies of information, that need to be kept in agreement, I typically use a routine to scan for disagreements and patch them up, rather than count on events or notifications.

- Events can be dropped or duplicated, so if it is important to keep track of changes, they can lead to errors. This is the "why wasn't I told" or "you already told me that" problem.

- It is easy to create event handlers, so easy that it is easy to create more than you want. This can lead to things like slow window painting because it's being done many times when it only needed to be done once. Then when you remove an event handler, you may think you've turned off the event handling, but you haven't, because you haven't removed all of them. This is the "spam" problem.

So as I said, I prefer to minimize event handling (and its cousins - notifications and nested properties), but to definitely employ them, sparingly, where their benefits will do the most good.