What is the “controller” in a web app?
People know what a “view” is (the “v” in MVC), but trying to get people to understand the difference between a “model” and a “controller” can be difficult. […] You can always yell at people and tell them not to put business logic in the view layer, but creating a mental model that explains why that’s a bad idea might help.
I generally think of it as business logic, HTTP translation layer, and templates, rather than as model, controller and view, respectively.
That there is the controller’s job: to munge the HTTP request into calls and parameters in terms of the business logic (the model), then take the results and turn them back into an HTTP response, for which it generally enlists the aid of a template subsystem, which is useful because the production of different responses typically involves shared functionality.
I find this way of thinking about the layers makes it easy for me personally to make the right distinctions between the parts of the job that belong to the controller vs the model. Maybe it will also work for others.