I am working on re-writing my application based on things that I learned at RailsConf 2009. I understand that the Model, Controller and View relate to each other. However, one thing that I have struggled with is the "proper" level for a controller.
If the Rails Model maps (roughly) to a database table... And if the Rails View maps (roughly) to a browser page...
What does the Rails Controller map to?
The controller is a means of connecting Model(s) to View(s) using the logic, constraints and conditions of your solution.
So, I suppose it could map to the "brains" of you solution.
The Controller really doesn't map to anything in the context that you're looking for. You have to think of the Controller as the glue that you use to put the Model with the View.
The Model lays out your data.
The View lays out the representation of data.
The Controller is responsible for taking the request and retreiving the proper model and view...then presenting that result to the user.
If your looking for a metaphor for MVC one that helped me get things a little easier when starting out I thought of things like this:
Model - Your Skeleton (Helps the structure of things)
Controller - Your Muscles (Helps everything get moving and do the needed tasks)
View - Your Outward appearance (It's how the world sees what the other two parts do)
That's the simplest way I could come up with myself to get myself to "Get it" hopefully it helps. Again, The Controler in this part would "map" to anything that is doing work for your applications.
Everybody is wanting to liken it to glue or muscle or something else but it's kind of a poor fit for any of those because it's a translator between the model and the view. Muscle does not serve an input function, only output, nerves and senses provide the input in that analogy. Glue just adheres two things together, it doesn't change them.
The controller layer in MVC is responsible for taking data out of the model and translating it into a form ready for the viewer to display it. A perfect example of that is three different pages which all present data in the same (or very similar) form but the data displayed comes from very different sources. In each of those cases the same view code might be being used, however the controller is the one who knows to call different functions on the model to get the data to display and put it into the right collection name so the view can find and display it, even though the view is actually ignorant of what it is displaying.
But that's not the only task for the controller layer because it also has to perform translation of the user's requests into actions on the model. The user clicked a link or typed something into a field or slid a slider and that may translate to one or more actions on the model. It should not be actual business logic of making decisions, but if for example you had a checkbox that said "do this three times" but the model only had a function to do something once, the controller would be responsible for calling the model's function three times to perform the action.
If you have to have an analogy, I'd use Michael's answer of "brains".
The controller is the manager or coordinator. Think of models and views as two different groups within a company (maybe sales and IT). The controller is the person that sits above those two and makes sure they play well together.
Having said that, all of these metaphors will be flawed in some way. For example, the controller usually ensures that a user is logged in for pages that require the user to be logged in. That doesn't really fit into my metaphor or some of the other ones.
The controller maps closely to the URL especially when using RESTFUL resources.
I like to think of the URL as the command line interface for your application.