• Created by Unknown User (logch_o), last modified by Unknown User (don) on 19-04-2008
Unable to render {include} The included page could not be found.

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
  • No labels

4 Comments

  1. Unknown User (alex)

    Maybe the concept of the Routed Event (pluses and minuses) is helpfull

  2. 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 (smile)

  3. 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.

  4. 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:

    • Notifications and events one-way are necessary between visual and non-visual components
    • Publishers and subscribers shouldn't know about each other
    • It should be allowed to use a multiplicity of N-M (many-to-many) between publishers and subscribers
    • The use of notication topics or channels for filter purposes (subscribers are only interested in specific notifications and dont want to know about other)
    • It should support a mutli threaded environment (think of the UI main thread and backgroundworkers running on others)
    • The use of weak references for minimizing the problem of getting memory leaks (event subscriptions are strong references and it is not always possible for the garbage collector to release the reference)

    I have created a prototype already. See EventBrokerPrototype.zip

Disclaimer