On MVC can several views have the same controller or one view must have one unique controller?

Question

I'm having some questions while designing a architecture for a project around MVC. (It's a C++/Marmalade SDK project, I'm not using any particular MVC framework, I'm making one.)

On several articles (like on the original Steve Burbek article) I keep reading the concept "MVC triad" which bogs me since I took this concept rather literally. When I read it the first time looked like an application is built around "MVC triad" units - one for each UI piece I supposed -, but I find this rather un-flexible and I think that's not how MVC was intended to be used. Then, researching further on the issue, I found several examples of tight coupling of the controller and the view, namely, 1-to-1 relationship - TextEditView has TextEditController.

But when I get back to my project I find that could be useful to have one controller (by 'logical unit', like AddElementController) and several views for that particular controller.

I'm clearly thinking about something like an AddElementController that should have some sort of tab UI. Should I have a AddElementController that has a AddElementTabView and several AddImageView, AddSoundView, etc for the tabs? Or should I have a different 'sub-controller' for each tab view?

In sum, and regarding the MVC pattern (not the X framework particular understanding/implementation of this pattern), is it correct to have several views for a controller or should each view have it's particular controller?

Also, is it correct to keep some state information on the controller or should it be stateless (meaning that the state should be placed on some non-domain state model)?

Thanks to all in advance.

Answer 1

The problem is that the MVC pattern was designed in a system that doesn't really exist anymore. It was invented in Smalltalk at a time when UI libraries did not exist. To make a window dialog you drew all the boxes, highlighted the appropriate squares, made sure that the text you were drawing ended up in the right spot...etc...

Imagine what it would be like to write a dialog app using nothing but one large canvas. That's the world the MVC comes from.

A "view" in this system was a text box and it was a class that was responsible for drawing the box, the text, drawing selected areas, responding to changes in the text, etc...

A "controller" was another class that took mouse events that occured within this box like mouse moving, key down, key up, clicks, etc...and it would decide what happened. Should we change the text? Should we change the selection? Stuff like that.

A "model" was yet another class that represented the basic data and state of the component. A text box model would have the text of course, the font, selection, etc...

As you can see, in a situation like this the three components are very entangled in the representation of a single idea. It makes sense in this context to speak of a "triad".

Today, if you're working on creating a UI library and using raw drawing commands you might do something similar. But the application of the "MVC" pattern has spread beyond its initial purpose. Now days you have a "view" that may actually be a complete dialog, and a controller that's responding to events like "textChanged" or "buttonClicked". The model in today's MVC is normally something fairly disconnected from the system (but generally linked to the view by providing an observer interface of some sort) and there may be many views associated with the one model.

In a system I recently architected for example we had around 10+ views all observing a single document "holder" and its active document. A main drawing interface interacted with the layout of the document, various property views that observed the selected item and provided a record interface, and a smaller scale representation of the main view that showed the entire document instead of just the visible window. Some of these views had controllers of varying complexity that turned GUI events into changes to the document, which would in turn notify its various views.

Can you still call such a relationship a "triad"? Perhaps, but I think it implies too much of the former, older application of MVC.

Could you share controllers with different views? Depends on how similar the views are. I've found that generally speaking this type of object has behavior to specific to the view it's controlling AND the model it is manipulating to be very reusable...but there's always exceptions.

Answer 2

It depends. There are several variants of MVC, some where only a 1:1 relationship makes sense (like "the humble dialog box"), others where this is not the case. I would recommend to read the "Build Your Own CAB" series of articles, explaining the most important MVC variants.

Answer 3

Views does not have Controllers in MVC. Controller is the boss, so a Controller decides which View to be rendered and Views does not / cannot care which Controller requested the View.

You can / will absolutely have multiple Views from a Controller. Just think about creating a model for each view if you want to stick up with MVC pattern.

Answer 4

The point of the controller is to control user interactions with your domain model--that is, it is a level of indirection between what the user sees (the view) and the state of your applications (the model).

When the user makes a request, it is directed to a controller. The controller decides how to relay that request to the application, usually through some sort of service class. It then interprets the response from that service class and decides what view to send back to the user.

A controller may always return the same view (1:1) if there's only one sort of request the user can make of the controller, and it always requires the same sort of response. For example, the HelloWorldController will always return a HelloWorldView displaying "Hello, World!"

On the other hand, a controller often has to decide on different views, depending on what the model tells it. The TeamRosterController might return a RugbyTeamRosterView or a FootbalTeamRosterView, depending on the type of the team requested.

It is generally preferable for controllers to be stateless, although some access to the state of the user session may be necessary or desirable. You should manage access to that state separately if possible.

I'd highly recommend looking at an actual MVC framework to see what it does and how it works. You don't have to use it, but you would definitely gain a better understanding before building your own.