MVC is an acronym which stands for “Model, View, Controller.” It is a methodology for separating code in an application based on its role.
All objects belong to one of the three categories and must follow implicit conventions.
There should not be any direct conversation between the View and the Model.
Views interact with the Controller through delegation or IBOutlets.
Represents the data, business logic, and state of the application. When creating classes that abstractly represent real-world objects that your program uses to store information or state, you are defining the Model.
Views are objects that contain all the code that deals with displaying content to the user and allowing the user to interact with the application.
In iOS all View objects subclass UIView. These subclassed objects contain everything from buttons to labels to images and each are independantly capable of interacting with the user on their own– you rarely need to subclass them. Just like System.out or Scanner above, you can use these objects “out of the box” to fetch or present strings (or a variety of other types of data) to the user
Two sample screens from Chase's iPhone app.
The Controller class of objects is responsible for managing the application's model and views. It acts as an intermediary between both and handles changes from either. Ultimately it has the highest precedence and most responsibility in iOS.
In iOS all Controller objects subclass UIViewController and are, by convention, suffixed by “ViewController.” For example, if you create a ViewController subclass that is responsible for managing the Home screen, you should name it HomeViewController.
Each of the three screens above are separate ViewControllers. Each of the images have different classes responsible for managing the different views while the app is running and each serves a different purpose.