I have heard two separate uses for the term controller when speaking of the Model View Controller methodology.
- An intermediary section of code that communicates between the Model and View, tying them together.
- 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.
5
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.