MVC design pattern. How does View fit it?

Question

I have a questions about the Model-View-Controller design Pattern. I understand the model holds the data. I also understand the Controller (View Controllers) implement the logic of the app. For example, if the UIPicker wheel selects row 4, then the View Controller can ask the Model for the 4th object stored in the Model's array. I'm having trouble understanding were the "Views" fit in. I would think that that nib / storyboard file would be classified as the "View". However every view requires that a View Controller be connected to wire up all the outlets to the view. How am I suppose to keep the View and the View Controller separated? Should I wire all the outlets to the "View Class" and then in my View Controller reference my "View" class when implementing the logic of those outlets? Maybe I just need an example where the View and the View Controller handle different tasks. Because otherwise the an extra "View" class doesn't seem to make sense. Is the View of MVC referring to a View Class? How or why would I want to have this View Class separated from my View Controller class?

Answer 1

A view's job is to display data and to report events.

The controller's job is to coordinate communication between views and models.

The data's job is store data and also to provide business logic around that data.

You asked:

I'm having trouble understanding were the "Views" fit in.

In your example, the UIPickerView is the view.

In iOS/OSX, a view controller is just the controller of MVC. It just so happens that a view controller also contains an empty view container that you can add all of the other views to. But there is still a clear separation of MVC in iOS/OSX.

All of the classes like UIButton, UIPickerView, UITableView, etc. represent the view. A view controller's job is to provide those views with data from data models as well as respond to events from those views giving you a chance to update other views and the data models.

You also stated:

However every view requires that a View Controller be connected to wire up all the outlets to the view. How am I suppose to keep the View and the View Controller separated?

They are separate. If you add a UITableView, that is a separate view. You connect it to a class so that class can implement the data source and delegate methods. That class is a controller class. It is common for this controller class to be a view controller but it doesn't have to be. You can write all kinds of custom view classes that are independent of any specific view controller (or generic controller). But eventually that view class needs to be hooked up to a [view] controller class so data and events can be processed properly.

You asked:

How or why would I want to have this View Class separated from my View Controller class?

Look at UITableViewController. This is a clear example of the separation but it is provided in a fairly neat package. You actually have a separate UITableView class which is the view. This view is responsible for rendering the view and gathering user interaction. It is the actual table view controller that provides the data to the view and handles the user events from the view.

You can add UITableView views to any view. This is a fully reusable view component. Each controller you hook up to a table view can provide any appropriate data and properly handle user interactions.