The controller in MVC does have a bit of a dual nature, firstly it acts as glue code between models and views, allowing the two to be effectively de-coupled. T

The controller in MVC does have a bit of a dual nature, firstly it acts as glue code between models and views, allowing the two to be effectively de-coupled. The second task is a little more complex - views take user input eg mouse-clicks and key presses, and translates it into semantic events "OK button clicked", "Open File selected", which are then acted on by the controller. Your post explicitly identifies these two roles and formally seperates them. This is perhaps not a bad thing, but I don't know that it justifies the title. Something like "The two faces of an MVC controller" might have been a better description...