[eluser]Colin Williams[/eluser]
One day, Request comes to town and it asks for a specific blog post.
It is greeted by the Blog controller, who makes sure everything checks out and passes the params that Request has brought along to Blog_model.
Blog_model goes to the database in the back and returns with a post.
Blog controller takes the pieces Blog_model returned and then worked with Views to piece it all together.
Finally, Request ended up with a nice package to send back to the Client.
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
Okay, so that might seem a bit pejorative to you, but the point I'm trying to make is that each piece is sort of an actor in a little scene. The controller is sort of the concierge for the HTTP request. In the scenario above, the controller was responsible for handling a blog object. The process was pretty simple, but imagine a Cart controller that was taking an order. It would have to build the order, generate the total, validate the payment, pass the payment to the gateway, handle the response, save the order, email the customer, email the store owner, and generate a receipt for the user, among many other things.
Controllers can sometimes be thought of object handlers, one for each unique object of your application. Blog posts, tasks, products, carts, categories, users: These are the kind of "objects" that would probably each get it's own controller.
So the point is, sometimes the Controller has a lot to do, so it's bound to get bloated in some cases. Models retrieve and format data, whether the data comes from a database, flatfile, or web service call. And a View formats the objects for display.
Controller: Handle request for objects (or actions on objects).
Model: Retrieve objects.
View: Format objects for display.
Just don't mix those roles, and you should be safe.
