Skip to content

Latest commit

 

History

History
87 lines (47 loc) · 3.29 KB

123-ios-architecture-patterns-revisited.md

File metadata and controls

87 lines (47 loc) · 3.29 KB
layout title date comments categories language references
post
iOS Architecture Patterns Revisited
2019-01-10 02:26
true
architecture, mobile, system design
en

Why bother with architecture?

Answer: for reducing human resources costs per feature.

Mobile developers evaluate the architecture in three dimensions.

  1. Balanced distribution of responsibilities among feature actors.
  2. Testability
  3. Ease of use and maintainability
Distribution of Responsibility Testability Ease of Use
Tight-coupling MVC
Cocoa MVC ❌ VC are coupled ✅⭐
MVP ✅ Separated View Lifecycle Fair: more code
MVVM Fair: because of View's UIKit dependant Fair
VIPER ✅⭐️ ✅⭐️

Tight-coupling MVC

Traditional MVC

For example, in a multi-page web application, page completely reloaded once you press on the link to navigate somewhere else. The problem is that the View is tightly coupled with both Controller and Model.

Cocoa MVC

Apple’s MVC, in theory, decouples View from Model via Controller.

Cocoa MVC

Apple’s MVC in reality encourages ==massive view controllers==. And the view controller ends up doing everything.

Realistic Cocoa MVC

It is hard to test coupled massive view controllers. However, Cocoa MVC is the best architectural pattern regarding the speed of the development.

MVP

In an MVP, Presenter has nothing to do with the life cycle of the view controller, and the View can be mocked easily. We can say the UIViewController is actually the View.

MVC Variant

There is another kind of MVP: the one with data bindings. And as you can see, there is tight coupling between View and the other two.

MVP

MVVM

It is similar to MVP but binding is between View and View Model.

MVVM

VIPER

There are five layers (VIPER View, Interactor, Presenter, Entity, and Routing) instead of three when compared to MV(X). This distributes responsibilities well but the maintainability is bad.

VIPER

When compared to MV(X), VIPER

  1. Model logic is shifted to Interactor and Entities are left as dumb data structures.
  2. ==UI related business logic is placed into Presenter, while the data altering capabilities are placed into Interactor==.
  3. It introduces Router for the navigation responsibility.