[MUSIC]

Hi, my name is Ahmed, and I was teacher and developer.

In this workshop we're gonna talk about MVVM, or

the model view view model design pattern.

A design pattern is a tested solution to a known design problem.

When we talk about design, we mean the architectural design of your application.

The way your code is organized and the way the objects talk to each other.

One of the most common design patterns and

the one recommended by Apple for iOS apps is the MVC design pattern.

You might remember MVC from a previous course here at Treehouse.

And even if you don't, well, here's a brief overview to refresh your memory.

MVC stands for Model-View-Controller.

It is a design pattern that assigns objects in an application

one of three roles.

Model, view, or controller.

The pattern defines not only the roles the objects play in the application,

it defines the way objects communicate with each other.

The collection of objects is sometimes referred to as a layer.

For example, the model layer or the view layer.

Here's a diagram that depicts how these layers communicate with each other.

The view communicates user events to the controller,

which in turn updates the model.

Conversely if the model receives updates it notifies the controller which

in turn updates the view.

We're creating these artificial constraints between the three layers,

these constraints are created to make it easier for

programmers to determine where each block of code belongs.

Now, MVC is a good design pattern, but after using it for a while,

you will notice that it starts breaking down.

We start abusing the controller.

From the diagram, you will notice that the controller is supposed to be

an intermediary between the view and the model.

However, it starts doing a lot more.

Sometimes it is used to lay out views, making network calls, getting data

from the persistence layer, preparing data for display, and so many other things.

Soon our controller becomes bloated and the MVC acronym gets a new meaning.

A massive view controller.

Now we've all been guilty of this, and this is nothing new.

We're rushed to add features, and

we stuff everything inside the controller keeping the view and model intact.

So a controller unfortunately becomes a kitchen sink.

Don't know what to do with something?

Well, toss it in the sink.

This behavior not only hurts our code, but

over time makes our app unmaintainable and untestable.

Thankfully the iOS community has borrowed a new design pattern

from the Microsoft community.

Yes, the MVVM design pattern comes from Microsoft.

Hey, but there's no need to hate on it.

MVVM shifts the responsibility between the controller and the model and

creates a new layer called the ViewModel.

The role of the ViewModel is a highly debated one in the iOS community.

Now, instead of fanning the flames of this argument, we're gonna establish a few

constraints and focus on the problem MVVM is trying to solve.

Let's take a look at the constraints we're going to establish for MVVM.

Why constraints?

Because constraints make it easier for us to write code as a developer.

The View only talks to the controller.

The controller can no longer talk to the model directly.

It only interacts with the View and ViewModels.

A ViewModel talks to a Model.

Besides the ViewModel, nothing else talks to the Model.

So what can the ViewModel do?

It can handle presentation logic for the View, for example, formatting a date.

It can handle business logic.

For example, the user subscription is about to expire, and a custom message

needs to be displayed based on the number of days left in the subscription.

Take the constraints as a guideline, a prescription,

to implement the MVVM design pattern.

So far, we've covered the basics of MVC and

how we can progressively evolve to the MVVM design pattern.

Now let's take a look at a concrete example on how we can

implement this design pattern.