Model View Controller

While developing an iOS application, we always face a challenge to manage the project so that it can be extended easily. We should always follow the best practices to develop any project. In this section of the tutorial, we will discuss the best practices that we use in the architectural design pattern to create an iOS application.

MVC is the most common and the easiest pattern to follow in the iOS application. Here, we will not be going to code anything, but we will walk through the projects that use MVC with best practices.

What is MVC?

MVC is the commonly used beginner-level software architecture design pattern made with the following objects.

• The Model contains the things that are used to handle the data of the application. The models are used to parse the request and response with the server's API. Things like persistence, model objects, parsers, managers, and networking code reside here.
• The View is treated as the face of the application. The object like UILabel and UITextField are the view objects that present the data on the screen. The view doesn't contain any domain-specific logic.
• The controller is used as the mediator between the Model and the view via the delegation pattern. The controller doesn't need to know the concrete view it is working for. However, the controller contains the business logic to present the data that is parsed by the model and displayed by the view objects.

Encapsulation of Data and Behavior (Model Object)

The Model layer encapsulates the data and behavior of the application. The model object contains the classes that hold the application's data. It also defines the logic that is used to manipulate the data to display in the application. All the important data is encapsulated in the model objects in a well- designed iOS application. The model object has no explicit connection to the user interface that is used to present the data in the application. In a dynamic iOS application that uses API calls to get its data on runtime, the request and response models are used to parse all the data that is coming from the server as a get API response or going to the server as the post API request.

Apart from Request and Response models, this layer may also consist of the other classes that are used in the project.

• Network Code: In each application that follows the MVC design pattern, only a single class is used to contain the network communication code. All the networking calls are made through a single class across the entire application. It helps us achieve the reusability in the code where the HTTP request headers and error handling are common to all the calls. It also achieves the flexibility in the code. We have to change only a single class in order to change the request in the entire application.
• Persistence Code: In the applications that maintain a local database within the application, this layer can be used to have the persistence code that is used when the app persists the data to the database.
• Abstraction Layers: Every application uses the managed objects that are used as mediator objects among the other classes. Abstraction layers can be the low-level wrappers, keychain wrapper on iOS, classes to handle the notifications, etc.
• Constant file: this is something that is managed by every iOS application. It is a file with all the constants used across the application. However, the constant must be stored as the group of the structures where the structure contains the variables having constants used in the different components of the application. Here, we can store the View Controller names, Screen text, etc. that are used multiple times in the project code.
• Extensions: Here, we can override, or add the methods to the built-in swift classes like UIViewController, String, UIColor, UIButton, etc. We can put the extension code in the model layer.

Presenting Information to the User (The View)

A view object contains the code to display the data from the application's model to the user. A View is not responsible for storing the data it is showing. However, a view may cache the repetitive data to enhance application performance. A View object is reusable and configurable to provide consistency between applications. The UIKit provides various view objects that are present in the XCode object library, which is being used in all the iOS applications that ensure that a view object, for example, UIButton behaves the same across all applications. A View object may allow the user to edit the data and therefore notify the model about the changes made by the user. The View layer contains the following category of classes.

• UIView Subclasses
• Core Graphics
• Core Animations
• The subclasses of Object library widgets to provide the common behavior to the object across the entire application. For example, the application may have to have a specific type of UILabel object across the application.

Tying the model data to View (The Controller)

The Controller object acts as the intermediary between the application's view and the model objects. The Controller makes sure that the view is displaying the correct model data. It also makes sure that the view interacts with the model classes. It manages the life cycle of other objects and coordinate tasks for the application.

The controller implements the delegate and DataSource object of the core view objects like table view and collection view for flexibility. It is the least reusable part of the application as it involves the domain-specific code. The controller contains the business logic of the entire application that defines the functionality of the entire application. A Controller defines the navigation among the views in the application and also defines when to access the application data or when to make a network call. A Controller can be seen as the brain, or engine of the application.