[eluser]kgill[/eluser]
Models, model. Ok so you probably wanted something a little more in depth than that, models are programmatic representations of an object you're interacting with. So if your app deals with students, all the properties and methods that a student would have go into your model. E.g. Students have names, they have grades, they are enrolled in classes, so you'd have various methods for doing all of that.
The idea is that the model deals with all the grunt work for the data, a controller doesn't need to understand anything more than that if it tells the model here's a first & last name create a student, it happens. It's the models job to know that last_name goes in the table my_students. This separation creates the infamous black-box, when the controller doesn't rely on how a model does something you can change table names or code inside a function and the app will still work so long as the parameters the model takes and what it returns remain the same.
So your controller is really the middle man for your data, it handles the decisions of what to do with the data it gets sent from the view as well as the data it pulls from the model.
Hope that helps clear things up.
