Refactoring Your Swift MVC Code: The Basic
If you are a programmer, I bet you’ve heard about it. The father of all the software patterns, Model-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 the user (interfaces of mobile or web app, etc). Model is responsible for the representation of application data. The Controller’s job is to handle user input and update the state of the Model to reflect the changes that were made as a result of user action.
Massive-View-Controller (MVC?)
While MVC sounds good in theory, it often doesn’t deliver on its promises in the context of swift and Xcode. The first time I used MVC, I put all of the function and overloaded it on the view controller.
That’s why I found someone on the internet called MVC as the “Massive-View-Controller” design pattern. It’s natural because, on swift, view and controller are somehow can’t be separated. They are encapsulated in a storyboard and corresponding Swift file.
Solution?
Model-View-ViewModel (MVVM)
Before we continue, there is no perfect design pattern and it depends on the problem and context. So what is MVVM?
I must admit that the Model-View-ViewModel (MVVM) design pattern itself is not that much different from what MVC intended to be. MVVM adds one component named ViewModel. It’s generally a class that sits between your model and your view controller.
ViewModel is supposed to be an “interconnecting chain” between the View and Model system components, and its 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.
In short, all UI will be handled by view controller and under no circumstance that the view controller interact with the model by itself. Every logic or operation between model and view controller will be handled by ViewModel.
Example
Here is an example of a MVC design pattern used on swift. Let’s say we are gonna make a food recommendation app.
We only need to focus on the view controller. As I’ve already said, the view controller in MVC will easily get overloaded because it’s responsible for both UI and Logic of application. You can see on the fetchFoodList() function, it interacts with the model FoodResponse itself. In short, that code above will be massive because it handled both UI and logic such as that API call by itself.
That’s why MVVM comes in handy. By adding one more class called ViewModel. It can separate the logic and the UI of our application. Our view controller only can handle the view or UI. The logic or interaction to model will be handled by our saviour ViewModel.
Let’s just get to the case and see for ourselves our brand new view controller
As we can see, the view controller is less messy because it only handles the UI. The VM variable that you see is our ViewModel. We pass it as a variable on the view controller to make things easier for the view controller to evoke certain command.
You may see on the bottom part there is an extension. It acts as an interface to our view controller. So, our view controller didn’t have to know how it gets food list, all it needs to know is it needs to execute fetchFoodList(). The reloadTable() and successMessage() is a function that will be executed by ViewModel.
If you are an observant, you may notice too this single line
What does it do? What does that even mean? Easy!
Remember on the MVVM diagram I presented to you that ViewModel has 2-way communication with view controller. Delegate is a variable in our ViewModel that keeps a connection to our view controller. That’s why we assign it with “self” which in this case is our view controller the FoodViewController.
What happened on the other side? The ViewModel I mean?
Well, this is what happened kiddos!
Just like that, we’ve created the food search screen that follows MVVM. It’s as simple as that. It keeps a connection to our controller by attaining delegate variable, and if our ViewModel ever need to do something with view controller, then it just needs to call it with the delegate. The example is with the success and error handled by the delegate.
The Model-View-ViewModel pattern helps to neatly separate the application logic and UI. It results in having single-purpose components that are easier to tested and maintained.
Keep in mind that this article/tutorial is not supposed to be the best practice. There are some things I kept simple because it will be a whole another topic. This is just the basic idea of migrating from MVC mindset to MVVM mindset in swift. For the best practice, I really encourage you to find more on the internet and a little spoiler, It will include a thing called protocol.
Good luck and keep curious !!
