#model view controller

The basic premise of MVC is to separate your objects into three “camps” - the model camp, controller camp, or the view camp.

• model- what your application is
• controller-how the model is presented to the user (controls how the model is presented in the UI)
• view - objects the controller uses to do what it does

These camps are all separate…so how do they communicate?

• controller -> model (since the controller is responsible for getting the model onscreen)
• controller -> view (since the controller uses the views by communicating through outlets to display the model)

The model and the view never communicate. The model is completely UI independent, so it shouldn’t have to talk to the view. The view should be as generic as possible (emphasis on reusability), so it shouldn’t have to talk to the model, which also greatly simplifies keeping track of everything.

The view can communicate with the controller, but it must be blind (can’t know what class of object it’s talking to), and well-structured. An example of well-structured communication is target-action, where the controller hands an action to an object in the view, and the view sends the action back to a target in the controller when something happens (e.g. button press).

Another example is delegation, when the view and controller need to synchronize. The view needs to tell the controller that something did happen, or something will happen, or ask if something should be allowed to happen. To do this, the controller sets itself as the view’s delegate through protocols.

Important: views do not own the data they display!! The view should be as generic as possible.