iPhone development and use of separate model files?

I've read a lot about MVC as I'm ramping up with iPhone / IOS development. However in the various sample files I've see so far I'm not really seeing separate classes for model, view & controller?

How should I concretely see MVC in action with a best practice developed iPhone application? For example perhaps one based on a NavigationController & some Table Views etc.

For example:

• Should there be a separate Model, View & Controller for each "iPhone UI controller" - noting that there seems to be 1 page == 1 UI controller in iPhone development from what I'm seeing, then my question is effectively should each UI Controller have it's own View file and Model file?

• Given that Interface Builder and NIBs are a big part of things, to what extent is a NIB considered to be part of the MVC开发者_开发技巧 pattern? e.g. does the creation of a NIB effectively implement the "controller" and the "view", leaving you to create a separate class (in a separate file) for the model?

• What happens when you've got shared data (or a shared model - e.g. a list of items) that is shared/used by multiple application pages (e.g. list view, edit view etc) - in this case this seems to me you would have 1 x model, but then reuse this model instance across the separate pages (which are View & Controller).

Hope this makes sense...

You'll be following MVC by using the objects and tools in their typical use. A UIView object is used to present data and receive input (View). A UIViewController responds to events and routes the data back and forth between the data model and the UIView hierarchy (Controller). Your data model lives wherever you want it to, sometimes composited together with your UIViewController subclass, sometimes present in the app as a singleton class (Model). When you specify your shared data model as a singleton class then any class that needs it can access it from anywhere in the app. By maintaining this division of labor, your application will tend to be well-organized and modular, and you can maintain/extend one aspect without having to rewrite all the other aspects of the program.

Interface builder is a tool for visually building the view hierarchy (and to some extent the control hierarchy) of your application.