MVC Design pattern for iOS development
I have gone through a lot of articles and blogs of CTO and senior iOS Developers to understand their perspective of different architectural design patterns. I would like to explain it in brief.
MVC stands for Model-View-Controller, as the name suggests it is distributed in three layers namely model, view, and controller, each has different responsibilities.
Let us learn about these three parts of architecture in detail.
Model – Model is responsible for data management. For example, persistent storage model, API response model, or Local file storage management in the document directory.
View – View is responsible for presenting data to users on the screen, which they got from the model through a controller. e.g Storyboard, XIB, Tableview Cell, Custom Views.
Controller – Controller is a middleman for both Model and View.
It will take input from the view, process it, and send it to the model if there is any data operation e.g., convert any string parameter to integer and pass it to model for saving it in persistent storage or call API request.
Similarly, when the model has some update in the data, it will notify the controller, it will translate it to user-readable format, and send it to view to present it on the screen.
Representation of all elements of MVC and their relations.
Pros
- Increase code readability, code is clean and easy to maintain.
- Multiple developers can work simultaneously.
- Easy to debug, because of the separation of responsibilities.
- Good module design - separate classes are kept for the model, view, and business logic.
Cons
- Tight coupling between controller and views, it makes difficult to write unit tests.
- View controller could be massive, the code becomes very difficult to manage and understand.
Why should we use architectural design patterns to write code?
Architectural design patterns help us to maintain and write scalable, testable code and new developers can easily understand the project structure and code.
Which one is best to design a pattern to follow?
I would say there is no good and bad design pattern. It is depending on different aspects of the project such as project and team size, potential features, and updates.
