Same like every house has a solid basement, every software project, has a software architecture it is built on, and each project has its own app structure. The types of architectural patterns may vary, but there are 4 most commonly-used ones - the ones whole IT world continuously criticizes but keeps using at the same time: MVC, MVP, MVVM and Viper (the last one as iOS architecture pattern mostly). The comparison of these patterns and choosing a better fit for each Swift-written project’s case will be discovered further on in this article.
Following the chronological order of things, once the first software design patterns have appeared, the common issues of those ios development architecture patterns didn’t take long to arrive.
For instance, the problem of server-client communication - how does one interact with another? Or a different one - the problem of separating the application’s business logic from the in-app’s logic; how this one should perform in terms of application’s architecture? Due to them various design patterns for different architecture layers have seen the world; the most well-known amongst them are:
- Singleton design pattern.
This pattern allows one class to be applied to one object only, and this option is of use when a limited amount of instances (or one instance only) is approved by the system.
- Decorator design pattern.
In contrast to singleton, this pattern, (alternatively called Wrapper together with the Adaptor pattern), lets a specific behavior to be added up to a single object (either statically or dynamically), and all of this without affecting the behaviour of other objects this one shares a class with.
- Bridge design pattern.
Firstly introduced by the notorious Gang of Four - authors of the book “Design Patterns”, this architectural pattern “uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.When a class aries often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge of the program. [Source: Wiki]
Despite those patterns being pretty different, the common problems of code-writers have occurred with each of them; for instance, with Singleton’s “massivity”. Singleton is too global, as the dependencies of your code are hidden deeply within your application, instead of being exposed in the interfaces. Which is why during the software development process new patterns constantly appear.
The 4 most commonly used patterns are MVC, MVP, MVVM and VIPER (for iOS mainly).
Developed in the same order as listed, all of them have their own benefits and flaws, causing numerous disputes about where to apply each one. Paying a bit more attention to the best practises they implement might clear things up a bit.
MVC pattern
The grandfather of all the software patterns, first introduced in early 1970s by a Norwegian computer scientist Trygve Reenskaug, Module - View - Controller, widely-known as MVC, is one of the first pattern approaches of the Object - Oriented Programming.
The View part is responsible for displaying everything for system’s user (interfaces of mobile or web app, etc.). Model is generally responsible for the databases, business entities and rest of data. In its turn, Controller regulates the Model’s work, data provided to the database, display from the mentioned database to the View part and vice versa.
However universal the MVC model might be, the two biggest competitors - Apple and Google have their own patterns representing Model - View - Controller system. The issue Apple’s system has lies in the tight connection between View and Controller parts, tight almost to the point of having united View & Controller, and leaving Model part separated.
Consequently, it results in poor testing process - only Model could be examined, V&C (due to the tight connection they have) can not be tested at all.
The robust connection between Controller and View segments proved to be truly “unhealthy” when it comes to software, so a new pattern saw the world soon.
MVP pattern.
Many of us have heard this shortcut in the context of Minimum Viable Product, but in terms of software engineering it means something different. The Model View Presenter pattern has few key points, forming a vast gulf between it and MVC:
MVP Model
-
View is more loosely coupled to the model. The Presenter is responsible for binding the Model to the View.
-
Easier to unit test because interaction with the view is through an interface.
-
Usually View to Presenter = map one-to-one. Complex views may have multi presenters.
MVC Pattern
-
Controllers are based on behaviors and can be shared across views
-
Can be responsible for determining which view to display
[Source: Infragistics]
In this arrangement Model’s functions stay the same; Presenter is responsible for the business logic respectively. The V part is the one of particular interest - as it is divided into two parts View and View Controller, which are in authority for interaction. When there is a MVVM vs MVC question, the system of this type solves the problem of a “heavy addiction” View and Controller modes used to have in MVC pattern.
The testing obstacle is also solved in this case, as Model, View with user interaction, and Presenter parts - all of these could be tested.
The yet existing inconvenience is in Presenter’s part - yet way too massive, yet takes into the account all of the existing business logics. Which is why the next act came into play, named…
MVVM pattern
A Model-View-ViewModel software architectural pattern has been created in 2005 by John Gossman, one of Microsoft’s architects. The three core components of MVVM model respectively are:
Model is “an implementation of the application's domain model that includes a data model along with business and validation logic. Examples of model objects include repositories, business objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.” [Source: Microsoft]
View is again everything that user is capable of seeing - the layout, the structure and the appearance of everything on the screen. Basically, within the application it would be app’s page. View gets and sends updates to ViewModel only, excluding all the communication between this part and Model itself.
ViewModel is supposed to be an “interconnecting chain” between the View and Model system components, and it’s main function is to handle the View’s logic. Typically, the view model interacts with the model by invoking methods in the model classes. The view model then provides data from the model in a form that the view can easily use, as Microsoft states.
The main difference between MVC and iOS MVVM is that MVVM’s distribution pattern is better than in the previously-listed MVC, but when compared to MVP it is also massively overloaded. Testing is a matter of particular importance here, as while plainly writing the code you can not guarantee that the whole project will function properly - tests, on the bright note, help to ensure it will.
The next architectural patterns’ evolution has been recently released and is now the freshest software architectural approach.
iOS VIPER architecture
Searching for the best architectural solution to deliver, iOS developers all over the world bumped into a so-called “Clean Architecture” approach, introduced by Uncle Bob on the Clean Coders - a well-known platform providing training sessions for the software professionals worldwide.
Clean Architecture splits the application’s logical structure into several responsibility levels. In it’s turn, this “separation” resolves the tight dependency issues and increases the testing availability of all levels.
VIPER for ios development
VIPER is a realisation of Clean Architecture for iOS-built applications. As a common rule for all the patterns’ names, it is a backronym as well, for View, Interactor, Presenter, Entity and Routing. Each of the VIPER’s parts is responsible for a certain element, particularly:
-
View is responsible for mirroring the actions user makes with an interface
-
Presenter’s responsibilities within the VIPER pattern are quite limited - it receives the updates from Entity, but doesn’t send any data to it;
-
Interactor is the system’s part that actually corresponds with Entities. This scheme works in the following direction: Presenter informs Interactor about the changes in the View model, then Interactor contacts the Entity part, and, with the data received from Entity Interactor gets back to Presenter, which commands View to mirror it for a user. All the data models, all the entities and all the websites are connected to the Interactor part.
-
Entity consists out of objects that are controlled by Interactor (titles, content. etc.)It never interacts with Presenter directly, only via I-part.
-
Routing (or Wireframe as it is sometimes called) is responsible for navigation between all of the screens, and, essentially, for routing. Wireframe controls the objects of UIWindow, UINavigationController and so on.
Particularly within iOS architectural system it is all built upon a framework called UIkit, which includes all the components of Apple MVC, but without a tight connection that used to drive coders mad before.
VIPER module is as well beneficial once it comes to unit tests, as the great pattern’s distribution lets you test all the functional available. In many ways this was the main difficulty developers faced with previous MVC, MVP and MVVM software patterns.
To Crown it All.
All of these 4 software design patterns are often called one of the best architecture Patterns for iOS development, even though all of them are less than ideal and definitely not universally used for each and every project you get to develop. On the gloomy side, here is a short list of issues each pattern has:
-
MVC, MVP, MVVM - all of them have this “tight connection” issue, which makes introducing updates to development, and testing them afterwards quite a harsh task to accomplish.
-
VIPER vs MVVM, MVC or MVP, is thought to be a winning case; although despite its high flexibility and great testability also has many nuances that are hard to generate.
Is there a 100% solid solution? Not really, but for each of your projects one of these 4 iOS app patterns might be just what you need. And if it is not, then a mixture of two would be. Or even maybe three. Fortune is said to favour the bold, so why don’t you play with software design patterns boldly?
Written by Max Mashkov and Elina Bessarabova.
