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?

  • Can you post some brief code that illustrates your model? There are ways to "soft-wire" dependencies (i.e. setting up the event handlers at runtime); if you look at the code-behind for a typical Winforms form, this is exactly what it does in the partial class constructor. There's no such thing as complete decoupling; your application is still going to need to know which form to open eventually, so unless you're building some sort of application generator, hard-wiring the name of the form to open is perfectly normal. Feb 2, 2016 at 23:03
  • @RobertHarvey Let me see what sort of sample I can come up with. I suppose the big difference is I have an object with centralized "window opening events."
    – Casey
    Feb 2, 2016 at 23:08
  • The use case for that sort of thing would be a "plugin" system where you could modularize the form components and swap them out at runtime. If the design of the application is intended to be static (i.e. the form will always be the same form that opens for its use cases), I don't see the need. Feb 2, 2016 at 23:10
  • @RobertHarvey Well, the presenters can raise the events without knowing about any of the forms. Wouldn't that not be the case if I were just listening for events on the forms themselves?
    – Casey
    Feb 2, 2016 at 23:18
  • 1
    I'm always skeptical about adding an additional level of indirection unless you derive some tangible benefit. What happens when you need to troubleshoot the thing? Do you have to suffer through a debugger session jumping through a new level of indirection until it gets to the real form/event? Is that even possible, if your Singleton appears in an assembly whose project source isn't loaded into Visual Studio? Feb 2, 2016 at 23:32


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.