3

I have heard two separate uses for the term controller when speaking of the Model View Controller methodology.

  1. An intermediary section of code that communicates between the Model and View, tying them together.
  2. The module that deals with input, similarly to how the view deals with output.

For starters, which definition is correct? I have read more that use the first definition than the second, with the second being the first one I learned.

In addition, it seems to me that both of those things are useful - indeed, when I've used MVC-like designs, I've used both of those things in some way (even if I only ever called one of them the controller). Should MVC really be defined in a way that includes both of these things? That would mean that the architecture contains the model, an input module, an output module, and an intermediate module to connect them all, and that just makes sense to me.

| improve this question | |
  • 1
    The intermediate layer is the later that deals with input, isn't it? – Izkata Mar 31 '13 at 4:00
  • What does "deals with input" means? If it means take the input and pass it to a model or a view (or both), isn't that "An intermediary section of code that communicates between the Model and View"? – yannis Mar 31 '13 at 4:03
  • "Deals with Input" means that it captures the input, be it from a keyboard, mouse, or gamepad. "Intermediary code" means that it takes data from one module and sends it to another. These may or may not be handled by the same code, depending on how you look at things - in fact, this ambiguity is the crux of the question. – Southpaw Hare Mar 31 '13 at 4:10
  • 1
    @SouthpawHare Capturing (user) input is usually handled by the view. But just capturing the input is not really interesting or useful, you got to do something with it. btw where did you read your definitions? And why are you assuming they are talking about different things? User input is just one of the many things a controller will pass around. – yannis Mar 31 '13 at 5:50
  • The view knows you've pressed some keys, clicked the mouse a bit, but that's about it. In some cases, the default controller in the component can do a bit more (e.g., updating a simple buffer model of a text field) but it still has no idea what this means. OTOH, it's rare that such a basic model is sufficient for a real application... – Donal Fellows Mar 31 '13 at 20:25
2

If you go to the origin of the MVC methodology, which lies with Smalltalk 80 about 20 years ago, then the second definition is the correct one.
In that time the OS support for user interfaces was still rather limited and most of it had to be done by the applications themselves. Within MVC, a collection of views would be responsible for updating the correct portions of the screen, while a collection of controllers (one for each view) figured out what to do with each key press.

In modern days, the OS takes most of the burden of figuring out what to do with a key press and the application only gets to know about it through the view components when the user confirms their data entry. This means that the controller of old has no place any more in a modern application, because its role is taken up by a combination of the view and the OS.

At the same time, the view classes get provided more and more by the OS or generig frameworks and thus they become more and more generic. This is where the first definition of controller fits in: To deal with the changing demands and responsibilities, the controller morphed into more of a glue component that ties the generic view classes with the application-specific (and GUI-agnostic) model.

To sum it all up, both definitions of controller are (in historic perspective) correct, but the first one is the more relevant nowadays.

| improve this answer | |

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.