The way it was explained was through the use of events and the publish/subscribe model. Basically, the model would just be the data and it would have no knowledge of the view/GUI/UI. The model is typically just an abstract object that operates on its data and can perform operations and whatnot.
The view is a different class that responds to changes in the model and usually displays this data to the user. Previously, I did not know how this could occur without coupling between the view and model but having it explained with events clears that confusion up a lot. Does this mean that the model contains public events that itself raises when something interesting happens? For example, if we were programming a game of Chess, when a piece was moved, the model would raise the event of PieceMoved with the necessary information (which piece, moved from where to where, etc.) and the view could subscribe to such an event and then show an animation of the piece moving from its old square to its new square.
The part that still confuses me is the exact nature of the controller. I'm having trouble understanding how it supplies the model and view with new information. I imagine the controller contains references to the model and view. Keeping with the Chess example, would the controller just respond to user input (for example to move a piece) and then just suggest to the model what piece wants to move to where? Then the model takes this information, sees if it's a legitimate move, and if so, update the model accordingly, raise the PieceMoved event, to which the view reacts and updates the graphical realm accordingly?
Lastly, how does the controller find out which piece is trying to be moved? It seems like that type of thing is heavily tied to the view (let's say moving involved first clicking the piece you wish to move and then the destination square). I imagine the controller would respond to a mouse click and sends those coordinates to the model but how would the model know how to translate those coordinates to find which piece was selected? Isn't that heavily tied to the view? It seems like the view would have to perform some logic processing instead of simply responding to the model and controller but then it wouldn't be a proper view anymore (instead a view/model mix).
The bad things about the MVC pattern are:
The good things:
To answer your question though:
The model
This is a easy one. The model should know only about itself. It is the board, the pieces and the rules of the game. You know you are building your model right if you could reuse it either in a desktop application or a web one.
The view
This isn't complex either. It is the visual part, and the one that deals with the user input. The most important concept to understand the role of views in the MVC pattern is that they must provide a way to make calls to the puclic interface of your system. In the chess game, it is the one that has to draw the elements and detect what the user is doing with the mouse/keyboard. When the user does something it is the view the responsible of calling the system: eg. "User1 wants to move piece from X to Y" (Important: most of the time you don't want the view to trigger a call like User1 clicked in coordinates x, y. Pixels are the realm of the view. The system has to receive orders that are independent of how they are graphically represented).
The controller
You're right, this one isn't that straightfoward. The controller is the one that has to process calls to the public interface to the system. In your example it will receive a call 'User1 moves from X to Y' and call a method in the appropiate object of the model (very likely the board in this case). Thus, the controller totally knows about the objects in the model. However it can also contain the code that is necessary in the application but that doesn't belong to the domain of your model. You have to check if the user has permission to access the system? You have to log that call into a file? Well, most of the time that kind of things go into the controller.
However, that's just my own version of MVC (I, like everyone else, also have my own too... :)