Scribd
Upload
219 views8 pages

MVVM Architecture

This document describes the Model-View-ViewModel (MVVM) pattern. It defines the roles of the Model, View, and ViewModel components. The Model contains the application's data. The View displays the UI and handles user input but contains no business logic. The ViewModel acts as an intermediary between the Model and View, containing business logic and exposing properties that the View can bind to. Coordinators manage navigation and inject dependencies like ViewModels. A dependency injection container manages object references and lifetimes.

Uploaded by

m4rc0sv
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as KEY, PDF, TXT or read online on Scribd
219 views8 pages

MVVM Architecture

This document describes the Model-View-ViewModel (MVVM) pattern. It defines the roles of the Model, View, and ViewModel components. The Model contains the application's data. The View displays the UI and handles user input but contains no business logic. The ViewModel acts as an intermediary between the Model and View, containing business logic and exposing properties that the View can bind to. Coordinators manage navigation and inject dependencies like ViewModels. A dependency injection container manages object references and lifetimes.

Uploaded by

m4rc0sv
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as KEY, PDF, TXT or read online on Scribd
You are on page 1/ 8

MVVM – Model View ViewModel

View ViewModel Model

UI Components Model Anything that


Reacts to and interpretation provides data or
interprets Business logic state to the
ViewModel through Bindable ViewModel
bindings properties Does not know
Contains no Dependencies as about ViewModel
business logic interfaces
Stateless May contain child
ViewModels
Does not know
about View
Model - MVVM
Anything (usually a class) that provides data or state for the ViewModel to
interpret
Should be injected into the ViewModel as an interface/protocol to improve
testability
Data and/or state be retrievable in small increments
View - MVVM
The view is the UI representation of a given ViewModel. From an Rx or FRP
perspective, the view is a pure function of the ViewModel.
Views define layout and user interactions
Views do not contain business logic
Views do not have dependencies other than the ViewModel
Like all dependencies, the ViewModel should be injected as an
interface/protocol to make testing easier
In iOS, both UIViews and UIViewControllers act as the View in this pattern
ViewModel - MVVM
The ViewModel is the combined interpretation of the business logic and the
Model layer that is to be presented to the user
All dependencies should be injected to the ViewModel and hidden behind
accessor functions or properties
ViewModel properties should be bindable
A ViewModel may contain other ViewModels representing subviews or acting as
a composite
A ViewModel knows nothing about the View
Coordinators
Coordinators are aware of the user’s context within the app
Primarily responsible for Navigation and ViewModel injection
Can contain sub-coordinators who are responsible for a narrowed context
Only object to have a reference to the Dependency Injection
container/resolver
Dependency Injection Container
Manages references and lifetimes of registered objects
Reduces the burden of dependency injection by keeping all injections in one
place
Greatly improves the ability to unit test your code by registering contained
objects as interfaces/protocols which can be substituted with mocks
Makes sharing observable data throughout the app trivial while keeping the
focus of each class/service small and independent
Special: Modal Pattern
The modal pattern applies to a view controller (or in some cases a very short
series of view controllers) that are presented modally and are context
(coordinator) agnostic.
Modal view controllers should be presented from an appropriate client-side
service, and therefore can be presented from anywhere.
Modal view controllers should use completion closures to handle what actions
should happen when they complete. The do not make use of the coordinator
or delegate pattern, because they are context agnostic.
iOS App Architecture
API

Back End Core Dependency Coordinators MVVM


BEWARE DTO Models Injection IoC Manage This is where
The unknown API Definitions navigation flow the magic
The black box
Container through the app happens
Manages Holds reference Passes data
aka Not your
content’s to DI Container back to
domain
lifetime Knows app Coordinators
Packages Contains:API context through the
CombineExt ServicesLocal Determines delegate
RxSwift Services ViewModel for pattern
Swinject ViewModels each View
SnapKit
etc…

You might also like