Model-View-Controller, or MVC, is a design pattern that centers on the idea that any class that you create should fall into one of three job categories: model, view, or controller. Here’s a breakdown of the division of labor:
Models are responsible for storing data and making it available to other objects. Models have no knowledge of the user interface or how to draw themselves on the screen; their sole purpose is holding and managing data. NSString, NSDate, and NSArray are traditional model objects. In iTahDoodle, your one model object so far is the NSMutableArray where tasks are stored. However, each individual task will be described an instance of NSString, and these will also be model objects.
Views are the visual elements of an application. Views know how to draw themselves on the screen and how to respond to user input. Views have no knowledge of the actual data that they display or how it is structured and stored. UIView and its various subclasses, including UIWindow, are common examples of view objects. In iTahDoodle, your view objects are the instances of UITableView, UITextView, and UIButton. A simple rule of thumb is that if you can see it, it’s a view.
Controllers perform the logic necessary to connect and drive the different parts of your application. They process events and coordinate the other objects in your application. Controllers are the real workhorses of any application. While BNRAppDelegate is the only controller in iTahDoodle, a complex application will have many different controllers that coordinate model and view objects as well as other controllers.
Figure 27.5 shows the flow of control between objects in response to a user event, like a button tap. Notice that models and views do not talk to each other directly; controllers sit squarely in the middle of everything, receiving messages from some objects and dispatching instructions to others.
It’s critical not to underestimate the division of responsibilities denoted by the MVC pattern. Most of the Cocoa and Cocoa Touch APIs are written with MVC in mind, and your own code should be, too. Now let’s return to our controller, the instance of BNRAppDelegate.