Currently events are handled very bad since everything is subscribed to everything (Project explorer to Model.DataItems.Added/Removed, Folder.DataItems.Added/Removed, etc.). As result it makes things very difficult to manage when objects are added / removed. Especially when these subsciption happen in external plugins (HABITAT, Verkenner...).
Better way to inform containers of the collections is to inform parent about changes (INotifyPropertyChanged) of the underlying object or let only container subscribe to collection contained in it.
In a few words:
Arrows show what object is subscribed to what.
Allowed Subscription of events
Anti-Pattern
In general the rule is: when you need to Subscribe / Unsubscribe frequently to events - you have to review your design of how event subscription is organized.
Consequences for DelftShell
- Refactor all subscription of events in ProjectExplorer, HABITAT, etc.
Points of interest
- INotifyPropertyChanging in .NET 3.5
- WeakEvent in .NET 3.5
4 Comments
Unknown User (alex)
Maybe the concept of the Routed Event (pluses and minuses) is helpfull
Unknown User (don)
Thanks for the link, yes, we should check it when moving to .NET 3.5 later. ... looks like I've just re-invented event bubbling
Unknown User (don)
Another article about more manual handling of events is here: Marc Clifton, EventPool, but I thing it is too manual for us, we should keep it simple.
Barry Faassen
A lot of components need to be integrated in the DelftShell. Event bubbling fits well in a small domain but is not a nice solution for a larger system having multiple components and many different assemblies. As stated components can all have references to each other for event subscriptions and this isn't a good practice. A good pattern would be to integrate components and notifications with a publisher-subscriber or message broker pattern. This encourages a loosly coupled relationship between them.
These are some factors influencing the design:
I have created a prototype already. See EventBrokerPrototype.zip