E.g I can't cleanly drop the component into another project without it requiring all sorts of other assemblies being carted along with it - usually these are client/project specific and have no place in another clients project. What follows is a session cutting these dependencies and extracting & patching up the core component...oh and by the way, development efficiency has plummeted because of the time spent on this.
The number of times I have seen code that would make a good general component "contaminated" by references to project or client specific literals, constants etc is unbelievable. Using events to gather configuration information, run time operating values etc is the way out of this.
- Events encourage "clean" design and promote a clear separation between components
- There is room for events within components that reside in tiers other than the UI
- Erm...I can't think of any more right now, however this article on http://www.codeproject.com is what got me thinking about events in the first place. This looks a great component if you are writing any application or service that needs to do something periodically...
Did I say I'm also a massive fan of promoting development efficiency? you know, "not reinventing the wheel" type thing...you knew that right? ;-)