model-view-controller architecture · model-view-controller architecture model-view-controller...
TRANSCRIPT
Model-View-Controller Architecture
Model-View-Controller Architecture
Model-View-Controller (MVC) is an architectural pattern, a standard design in the field of software architecture.
Heavily used by Apple in writing iOS apps, so understanding it is critical.
MVC divides the objects in your program into three “camps”.
Controller
Model View
Model: Encapsulates data and basic behaviors
Holds an application’s data and defines the logic that manipulates that data.
Responds to requests for information about its state, and responds to instructions to change state.
May notify other objects when its state changes.
Can be as simple as a single integer data member, or as complex as a collection of classes interacting with a database.
Controller
Model View
View: Presents information to the user
Knows how to display, and might allow users to edit, data from the application’s model.
Multiple views can exist for a single model for different purposes.
A view should not be responsible for storing the data it displays.
In iOS, each “screen full” of information is typically a view.
UI elements such as buttons, sliders, text fields, etc. are also typically view objects.
Controller
Model View
Controller: Ties the Model to the View
Acts as an intermediary between the application’s view objects and its model objects.
Receives user input from view objects and initiates a response by making calls on model objects.
When the state of the model changes, the model communicates that change to the controller, which then requests one or
more view objects to update themselves accordingly.
Controller
Model View
It’s all about managing communication and separating concerns
Limiting and structuring communication makes it easier to design programs.
Separating concerns allows Models and Views to be re-used in different applications.
Controller
Model View
Controllers can always talk directly to their Model
Controller usually maintains object references (pointers) to Model objects.
Object references allow Controller code to send messages to the Model objects.
Controller
Model View
Controllers can also talk directly to their View
A Controller usually maintains a special type of object reference (called an outlet) to View objects.
Outlets allow Controller code to send messages to the View objects.
Controller
Model View
Outlet
The Model and View should not speak to each other!
Controller
Model View
Outlet
No communication!
Can the View speak to its Controller?
Yes, to some degree.
Communication is “blind” and structured.
There are several common patterns of communication allowed.
Controller
Model View
Outlet
?
No communication!
1. Target-Action Pattern
An action is a message emitted automatically by a Cocoa UIControl interface object (a View object called a control)
when the user does something to it, such as tapping the control.
The various user behaviors that will cause a control to emit an action message are called events.
Controller
Model View
Outlet Target-Action
No communication!
1. Target-Action Pattern
Controller needs to define the action message (as a method of one of the Controller classes).
Controller needs to inform the control of three things:
o What event should trigger the sending of an action message.
o What instance should be sent the action message.
o What the action message’s name should be.
When the event occurs, the control sends the action message to the specified instance, which can then take appropriate
action.
Controller
Model View
Outlet Target-Action
No communication!
2. Delegate Pattern
Sometimes the View needs to synchronize with the Controller.
The Controller sets itself as the View’s delegate.
The View has an object reference that can point to any object that conforms to a particular delegate protocol.
The Controller must conform to that protocol (implement the methods that it defines).
That allows the View to call those methods in the Controller without knowing the Controller object’s exact data type.
Controller
Model View
Outlet Target-Action Delegate
No communication!
3. Data Source
Views do not own the data that they display.
A data source is a type of delegate that allows a View to acquire data it needs to display.
Controllers are almost always the data source, not the Model itself.
Controllers interpret/format Model information for the View.
Controller
Model View
Outlet Target-Action Delegate Data Source
No communication!
Can the Model talk directly to the Controller?
No. The Model should be UI independent.
So how does the Model inform other objects that its state has changed?
Controller
Model View
Outlet Target-Action Delegate Data Source
?
No communication!
The Model can use a “radio station”-like notification mechanism to “broadcast” changes to interested objects (called
observers).
Key-value observing is another mechanism that allows observer objects to be notified of changes to specific properties
of an object.
Controllers (or another Model) “tune in” to interesting stuff.
A View might “tune in”, but probably not to a Model’s “station”.
Controller
Model View
Outlet Target-action Delegate Data source
Notification & Key-Value Observing
No communication!
Larger iOS applications consist of many MVC “triads”, all working together.
References
APPLE INC., 2010. Cocoa fundamentals guide.
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/Introduction/Introduction.html
BUCK, E. M. AND YACKTMAN, D. A., 2010. Cocoa Design Patterns. Addison Wesley, Upper Saddle River, NJ.