MVC design pattern. How does View fit it?

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.

Ok, I will try to sort things out a bit.

The pattern is called Model-View-Controller, thus clearly separating the Model, the View and the Controller. As you correctly pointed out, the ViewController puts things together (from the View and the Controller :) and actually the ViewController breaks the strong MVC pattern. The good news is: you don't have to separate the view and the controller if you are using a ViewController (guess why it is named that way?).

Now my nooby explanation of why the design is what it is:

When you strongly separate the View and the Controller you basically earn credit points for good design. However, as it turns out, the two of them are not as separated as we'd like them to be. Different GUI representations usually do require a different view implementation as well as an adaption of the controller that controls the forwarding of the Model to the GUI, e.g. plain text display on the console vs. drawing on a bitmap. In the first case, your Controller would pass a string to the view to be rendered, in the second it would also need to set some coordinates in order to get the text rendered into the right place. Consequently, your controller is going to change quite often.

The ideal case would be to implement the model, and the controller and simply provide views for anything that anybody is ever going to see in real live. However, in real life situations, the controller will most likely adapt to the view while leaving the model alone. Thus the design decision to combine the view and the controller to a ViewController which contains a particular view and knows how to use it is just a reasonable way to go.

Actually what you understand is completely wrong.

The core principle behind MVC design pattern is Separation of Concerns. You separate model layer from presentation layer and (in the presentation layer) you separate views from controller.

Each of there pars have a different responsibility:

• model layer contains all of the business logic. That includes interaction with storage, domain logic and application logic.
• view is responsible for UI logic. In context of Web this means, that view deals with creating response for the user
• controller is the part that takes the user input and , based on that, changes the sate of model layer and current view.

There are a lot of misconception about MVC that people tend to perpetuate. For example:

1. Some will insist that views are dumb templates. They are not.

   Views in MVC design pattern are fully functional instance which deal might or might not use multiple template to generate the response.

2. There are no "models". Model is a layer, that consists of multiple different groups of classes, each with specific task. Same way as there are no "presentation" objects for presentation layer

3. Controllers do not send data from model layer to views. Controller only changes the state of other parts of triad. The view instances themselves request what they need from model layer.