At work the product i get to maintain has a lot of "moving parts" one of the main sticking points I have with how its architected is that should ten different locations need to know that a new item in a list is selected, a direct code path must be coded. For example in the following layout.
Form1
|
+-------------------+---------------------+
| | |
Control1 Control2 Control3
| | |
| +-----------+ +----+----+
| | | | |
SelectionList View1 View2 View3 View4
(The real application I work on has more layers than this for the GUI components... bleh...)
If we add another view to any control, which depends on which item is selected, Form1 needs to route the message. Worse yet, if we add various commands which could be invoked on a selected item, from the selection list or any of the views, the views need to be modified, to properly invoke the action. Usually such actions are housed in Form1 (and available via a main menu option too...)
(Think of the SelectionList like a list of files...)
This seems fragile and cumbersome.
Lately I've been toying with the idea of making (or acquiring if the price is right) a subsystem within an app that the publishers of events (such as commands) and subscribers only need to know of the definition of the event arguments and the name of the event in order to receive the event.
My questions are:
Is there a commercial, open-source, or public domain library that already does this in .Net 3.5? (I use C#.) This needs to be an INTRA-APPLICATION mechanism. I already know of interapplication libraries and mechanisms like MSMQ and This Codeplex project.
If you have experience developing or using solutions like these, what are the top 3 pitfalls to avoid?