M-V-C in iOS

Choosing a good architecture is essential because it can save you a lot of headaches in future especially when debugging or refactoring.

Three things to consider when choosing a good architecture

• Distribution – We don’t want classes with multiple responsibilities. Better to adopt single responsibility. As Robert C. Martin AKA Uncle Bob expresses, "A class should have only one reason to change."

• Testability – Distribution of concerns allow ease of testing.

• Ease of Use – Good distribution and duplication free supports extendibility and easy to maintain code base.

With the basics out of the way lets look at MVC.

MVC?

MVC is defined as Model-View-Controller, a design pattern that has been around since the early days of Smalltalk and it is a pattern that is recommended by Apple (be careful not to end up with a Massive View Controller, more on that later!).

A Model is where your data resides, for example API response, parsing jobs etc. it’s a data structure with most of the business logic. A Model has no explicit relationship to the View so it should not be concerned with how it’s data should be presented to the users. Model and View are decoupled.

A View as you guessed is what the user see and its considered “dumb” as all it knows is how to draw itself and respond to user actions. Because of this, views are highly reusable as they don’t contain any business or domain logic.

A Controller is an intermediary object of one or more model and view objects. A controller is a channel through which view objects learn about changes in model objects and vice versa. It can also perform setup and coordinate tasks for an application and manage life cycle of other objects.

A simple example

In this example we are going to build a random number generator.

RandomNumberModel.swift

This class will be our model. All this class will do is generate a random number between 0 and 1000 when calling fetchRandomNumber()

RandomNumberView.swift

This class will be our view. It's a simple view with a label, IBAction for our button and a block which gets called on button select. The view conforms to the DisplayNumberView protocol so that functional concepts of the view are well encapsulated for the controller to communicate without knowing its concrete type. This will make testing the controller easy as the associated view can be mocked and replaced.

RandomNumberController.swift

This is our controller, as mentioned previously it is responsible for managing the interaction between view and model objects and vice versa.

Lets break down the logic:

1. When users tap on a button on the view, the onDidSelectRandomButton block gets called which is set as the fetchRandomNumber function.

2. The fetchRandomNumber function asks the model for a random number.

3. The returned random number from the model is then sent to the view to be displayed however it likes.

As you can see the controller sort of acts as a mediator who doesn't care about the implementation dynamics or the UI style but rather the delegation and wiring.

By adopting MVC we achieved a clear separation for our application’s data/logic, views and controllers. But in reality your application may not as simple as this as it may contain other feature such as networking, collection views or image processing etc. As the responsibilities increase apps that use MVC tend to have absolutely "Massive View Controllers" which do everything from managing UICollectionView delegation to API Response parsing.

Should I use MVC?

This will depend on you application. If you are building a relatively simple app, MVC most likely be perfect but for an app with large number of screens, features or functionalities you are better off with the MVVM or VIPER patterns.

Download the above example here.

Peace✌