I should probably open this by saying I do mostly Web applications at work, which obviously have some major differences from typical desktop stuff.
I had a small Windows Forms program I'd made for myself. As I went to update it and add some stuff in I found that the program and presentation logic was too tightly coupled and it was unpleasant. First I broke things up by using the MVP pattern and having separate presenters that only interact with the forms through an interface. That was a start but I still had the issue that as a button press opened up a different form my form had to know what form it was going to call and what dependencies it or its presenter had.
After pondering it a bit, I came up with and implemented this design: a singleton has a different event for all the different kinds of windows you might want to open along with custom event arguments containing any contextual information these might need. A different class is responsible for registering listeners to these events and using a dependency injection container to retrieve any dependencies, get the presenter, get the window, connect them, and show the window. When I want some action to cause a window to open, instead of constructing a new window directly, I can simply raise the event in question -- meaning I could even go and swap out, for instance, a WPF form and not have to change any of the code that might cause it to launch.
In a way, this brings things a little bit closer to the "stateless" model I'm more familiar with. It seems to work well and I find the code easier to work with. However, after doing some searching I can't seem to find anyone else using this sort of model, which gives me a bit of pause. Are there some drawbacks to this model, or is this a good way to encourage more loose coupling between different forms in a GUI application?
