2. Back to 1970s - MVC
It was at the beginning
Apple's result
● Controller changes Model and update View.
Controller can have many views
● View represents information from the Model
● Model is a data/logic/rules
3. MVC - conclusion
● Drawbacks
○ The View and the Model in fact are separated, but the View and the
Controller are tightly coupled
○ Difficult to test and maintain
○ Cause a massive ViewController
● Benefits
○ Cocoa MVC is the best architectural pattern in terms of the speed
of the development
○ Everyone is familiar with this approach
5. MVP - passive view
● The Model is the data
● The View is a passive
interface that displays
data and routes events
to the Presenter
● The Presenter retrieves
data from the Model,
and formats it for display
in the View. UIKit
independent.
7. MVP - supervising controller
The main difference from
a PassiveView MVP is
Data Binding
This version of pattern is
less popular because of
tight coupling between the
View and the Model
8. MVP - conclusion
● Drawbacks
○ Time consuming
● Benefits
○ The responsibilities are divided between components
○ Reusable components
○ Testability is excellent, we can test most of the business logic due
to the dumb View
9. MVVM
● The Model is the data
● The View represents the
data from ViewModel
● ViewModel knows about
the Model and
fetch/create/update a data
and notify the View about
changes. UIKit
independent.
11. MVVM - conclusion
● Drawbacks
○ Data binding between the View and the ViewModel can be
compicated
● Benefits
○ The ViewModel and the Model can be easily tested because are
independent of UIKit
○ The responsibilities divided between components
12. Code examples
You can find Xcode project with examples MVC, MVP and
MVVM on GitHub page:
https://github.com/voloshynslavik/MVx-Patterns-In-Swift
Notas do Editor
Today we will talk about three most most popular architecture patterns in iOS MVC MVP and MVVM.
First of all we will look at structure and then will check how does it look in code.
I wrote simple one screen application that downloads photos and displays them in UICollectionView.
So, let's start from the oldest one - MVC
Here we have 3 main components Controller View and Model
In this case, the View is stateless. It is simply rendered by the Controller once the Model is changed.
What did Apple?
They combined View and Controller into one entity that calls viewcontoller
let's see how does it look in example
Classical MVC is usuful but not in iOS, because it causes big amount of problems.
To be honest I'm not sure that we can call this MVC that provides us Apple. This approach is the main reason why we have code that can't be covered by tests and a MassiveViewController.
It's difficult to belive in it, but there are even benefits. At least everyone knows how to write a code in this style and this pattern is the best one if you need quickly check something, for example proof of concept or prototype.
This pattern is more powerful than the previous one.
MPV has 2 different modifications: first Passive view and second supervising controller.
Let's start from Passive view and then check the differences between them
The Model is the same as in MVC but Presenter and a View are completely different
The presenter is the cental part that knows about Data and View.
Between presenter and model there is typical connection. Presenter has a link on the model and model notifies about changes via calback or delegates
But There is an interesting connection between view and presenter.
Actually this part between view-presenter contection was the most confusing for me. They have a link on each other. It means thas one of them should be declared as a weak reference.
Here you can see how it works
User, for example, press button and View cathes this event
Then redirect the event to presenter. Presenter handles it somehow, do something with model and updates the View at the end
As you can see this version of MVP pattern looks the same as the previous one. But here we see data bindling with a model.
This pattern is quite complex to understand at the beginning and probably it's the most time consuming pattern from an MV* generation.
But in the end you will get the flexible structure that can be easy covered by tests.
The reusability is marvellous. You can reuse everything.
Let's imagine that the same screen with CollectionView that represents list of images from Instagram, then we need to simply add new Presenter that downloads photos from another source.
And vise-versa if we want to add new new screen with table view instead of collection view, or just show single image. You need just change a view, but presenter can be the same.
This pattern is more familiar us then previous 2.
The view has a reference on view model, and viiew model has a reference on the model.
One important think is that viewmodel is uikit independent. It means that we can't use classes from UIKIt framework.
The quality of image is not the best, but I hope that you see what is there
so, how does it work in general?
for example user clicks on the button, view catch this event and asks ViewModel to handle it. then view model update model and notifies the View about result
And conclusion
If talk about bad side of viewmodel it can be data binding. It is easy to track changes in viewmodel if you have only one object, but if track for example 5 and everyone has own callback or delegate it's became messy
but viewmodel pattern is good in that sense that responsibilities are devided between components and these components can be easily tested