MVx patterns in iOS (MVC, MVP, MVVM)
•Descargar como PPTX, PDF•
3 recomendaciones•1,341 vistas
A brief overview of software architecture approaches in iOS. Example: https://github.com/voloshynslavik/MVx-Patterns-In-Swift
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a MVx patterns in iOS (MVC, MVP, MVVM)
Similar a MVx patterns in iOS (MVC, MVP, MVVM) (20)
Último
Último (20)
MVx patterns in iOS (MVC, MVP, MVVM)
- 1. MVx patterns in iOS
- 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
- 4. MVP ● Passive view ● Supervising controller
- 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.
- 6. MVP - sequence diagram
- 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.
- 10. MVVM - sequence diagram
- 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 del 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