iOS design patterns: MVC, MVP and MVVM

Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved.
C2M - Mobile App
Architecture
iOS
- Suyash Gupta

Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights reserved.Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 2
Agenda
• Separation of Concerns
• MVC
• Problems with MVC
• MVP
• MVVM
• Working MVVM App

Separation of concerns
• In computer science, separation of concerns (SoC)
is a design principle for separating a computer
program into distinct sections, such that each
section addresses a separate concern.
• When concerns are well-separated, individual
sections can be reused, as well as developed and
updated independently.

M-V-C (Model View Controller)
• A proven pattern for organizing your code in complex
application design, also the Apple recommended way
of programming an app.
• It’s also proven to have a second meaning in iOS
development: Massive View Controller.
• Apple hasn’t provided any real guidance on how to
solve the Massive View Controller problem

MVC
DEMO

Web MVC

Apple’s MVC
Code:
var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell
userCell.configureWithUser(user)

Problems with MVC
• Distribution— the View and the Model in fact
separated, but the View and the Controller are tightly
coupled.
• Testability — due to the bad distribution you’ll probably
only test your Model.
• Ease of use — the least amount of code among others
patterns. In addition everyone is familiar with it, thus, it’s
easily maintained even by the inexperienced
developers.

Problems with MVC

MVP
DEMO

MVP

MVP- Features
• Distribution — we have the most of responsibilities
divided between the Presenter and the Model, with the
pretty dumb View
• Testability — is excellent, we can test most of the
business logic due to the dumb View.
• Easy of use — in our simple example, the amount of
code is doubled compared to the MVC, but at the same
time, idea of the MVP is very clear.

MVVM
DEMO

MVVM

Some rules of MVVM
• The View has a reference to the ViewModel, but not
vice-versa.
• The ViewModel has a reference to the Model, but not
vice-versa.
• Business logic controller(VM) should have no reference
of UIKit.
• View should be only responsible for UI handling.
• View should not interact with Data Model or vice-versa.
• View Model is responsible only for processing input to
output and logic required for driving the UI as in demo
example.

MVVM-Features
• Distribution —MVVM’s View has more responsibilities
than the MVP’s View.
• Testability— the View Model knows nothing about the
View, this allows us to test it easily.
• Easy of use — its has the same amount of code as the
MVP in our example, but MVVM would be much
skinnier if you used bindings.[ReactiveCocoa]

Working MVVM App
DEMO

References
• https://academy.realm.io/posts/krzysztof-zablocki-mDevCamp-ios-
architecture-mvvm-mvc-viper/
• https://github.com/blkbrds/arch-mvvm-ios (Remove the lint pod from
podfile and build phases to make the project run)
• The references of the all the patterns are available on
Github:https://github.com/suyashgupta25/iOSPatternsSamples

iOS design patterns: MVC, MVP and MVVM

Recommended

Recommended

More Related Content

Similar to iOS design patterns: MVC, MVP and MVVM

Similar to iOS design patterns: MVC, MVP and MVVM (20)

Recently uploaded

Recently uploaded (7)

iOS design patterns: MVC, MVP and MVVM