The Cocoa frameworks and the Model-View-Controller pattern go hand in hand. A typical iOS application, for example, is composed of models, views, and view controllers.
The model and view layers are glued together by the controllers of the application. Those controllers are instances of UIViewController . A controller is responsible for everything that isn’t related to data handling and presentation. And that’s quite a bit:
- User Interface design
- Updating views with model data
- Responding to user input
- Saving and restoring state
- Data Source and delegates
- Animation
- Networking
- Navigation to other ViewControllers
This often results in the Massive View Controllerble or testable and their code is difficult to understand. I see them every day and I really can’t understand why programmers are still organising their code in this way.
In Soroush Khanlou blog you can read about how to answer this malaise and I really recommend you reading his extraordinary posts:
- 8 patterns to help you split massive View Controller:
- Data Source
- Standard Composition
- Smarter Views
- Presenter
- Binding Pattern
- Action Pattern
- Keyboard Manager
- Navigator
- The coordinator or director pattern
- Coordinator Redux
- Using tiny View Controller
