I've struggled a bit with the MVC approach to programming Web or local gui apps for some time. I learned tonight there are two different definitions for the controller "C".
Here's my favorite.
The two meanings aren't as different as they seem. In both cases, the Controller is the element responsible for processing change. Whether the major work here is in capturing user input or routing the different layers depends on the environment.
In WebApps, a Controller has to authenticate, parse the request, validate it, and deduce the appropriate procedures (or methods to run). This is all a consequence of WebApp 's being remote (so we need validation), stateless, and done over a narrow channel (URL + request). So, the Controller functions mainly as glue.
In a local rich client GUI, on the other hand, none of this is necessary -- it's stateful, so there's no need to load a context. It's local, so we don't need to worry about validation. It's in process, so we don't need to parse requests and deduce procedures -- we can just hook them up in source (via callbacks or delegates or whatever). On the other hand, we do need to spend a lot of time capturing and deducing user input from keys and the mouse. So, it makes sense to call this element the controller. (In WebApp's, this is all done for us, and serialized to a narrow channel -- the URL and request).
In both cases, the Controller is the element for processing and routing change. The difference is only whether the bulk of that work lies in capturing the input or setting up an app flow based on it.
Also see http://en.wikipedia.org/wiki/Model-view-controller