How to apply the MVC pattern to GUI development

Question

I am primary a web developer but I do have a very good understanding of C++ and C#. However, recently I have writing a GUI application and I have started to get lost in how to handle the relationship between my controller and view logic. In PHP it was very easy - and I could write my own MVC pattern with my eyes closed - mainly because of how PHP is stateless and you regenerate the entire form per request. But in application programming languages I get lost very quickly.

My question is: how would I separate my controller from view? Should the view attach to events from the controller - or should the view implement an interface that the controller interacts with?

Answer 1

Imagine this GUI:

The Zergling unit is presented to the user as an alien icon. You can see that it is in its idle animation. Call this the View.

The player moves the unit by clicking on it and a target location. You can subtitute the player for an AI if you want. Call this the Controller.

The HP and attack range of the unit is calculated every game frame when the unit is in combat. You can change this data to make the Zergling into a range unit. Call this the Model.

Keep this analogy in mind and extend it for your MVC designs.

Answer 2

If I was you I would expose events from an interface of your view. This would allow you to make the controller central to the entire interaction.

The controller would load first and instantiate the view, I would use dependency injection so that you don't create a dependency on the view itself but only on the interface. The controller would access the model and load data into the view. The controller would bind to events defined on the view interface. The controller would then handle saving of data back to the model via an event.

If you wanted to you could also use an event broker which would void the need to declare an interface per view. This way you could bind to events through attributes.

This would leave you with the Controller being dependent on the model and the view interface, the view being dependent on the data only and the model having no dependencies.

Some examples of the above design thinking can be found in CAB and the Smart Client Software Factory Link To Smart Client. They use the MVP pattern but it could equally easily be applied to the MVC pattern.

Answer 3

The imortant thing for you to remember, is that in your MVC setup the Controller must know which View to call, but the View must know nothing of the Controller.

So your View must provide a generalized way for Controllers to interact with it, so that you can have several different Controllers call the same View (a standardized graphical output of some data provided as parameter, for example).

This gives you flexibility:

1. If your customer wants PDF output of something you only provide HTML output for, you can get away with writing a new PDF View to be called from the Controller with the same parameters as the HTML View.
2. If your customer wants similar HTML output of a different data source (say), you can get away with coding a new Controller that provides a different data set to the same old HTML View, which gives the same HTML report just with other data.

If you keep your View detached from specific Controllers, and put the knowledge about which View to call from your Controller, you're well on your way.

Answer 4

Your controller should definately bind to events defined on an interface the view implements.

How you go about doing this can be the tricky part. Dependency injection? A view factory? Have the view instantiate the controller it wants? It really depends on how complex the application is going to be.

For something really quick and simple I would start with having each view construct it's controller and then look at other options if it needed to get bigger. Personally I think a full dependency injection framework is overkill for half a dozen forms :]

Answer 5

Most every GUI framework (from MFC to SWT to whatever) is already MVC based. In fact, the MVC pattern was first created by Smalltalk-80 and later first really used for GUI development.

Double check and look at the standards and suggested practices for your GUI toolkit of choice. Sometimes MVC won't be a good pattern to work with when solving a certain problem or working with a particular toolkit.

Remember: MVC is a great pattern but isn't a one size fits all solution, don't try and force a problem into MVC when event-based or functional style programming will make your life easier.