How MVC Architecture works

What is the MVC?

MVC stands for Model — View — Controller. It’s a paradigm. It allows a coder to factor out the various components of an application and more easily update them. The MVC allows the programmer to create barriers to organize the code allowing a programmer to compartmentalize functionality.

The MVC divides up all the objects in our program into one of the three locations (or camps).

Model — is what your application is (not how it is displayed)

View — The Controller’s minions, generic reusable interface objects that the Controller is using to do its job. Ultimately, how the model is displayed on screen. Most of the objects in the view (Buttons, Sliders, text)

Controller — How your Model is presented to the user (UI Logic); Platform-specific

Ultimate, the MVC architecture is about managing communication between the ‘camps’.

Controller has unlimited communication

The Model and the View should never speak to each other.

Three (3) primary ways the view speaks to the controller

(1) Target-action — Controller hands an action out to the view that it’s interested in hearing from (i.e. a button, slider, etc.) When the UI gets touched, the action gets sent to the target, which is placed on the Controller.

(2) Delegation — controller sends a message and becomes the delegates to the view stating
The delegate is set via a protocol (i.e. it’s blind to a class).

(3) Data source protocol -

The controller’s jobs is to interpret the data for the view.

There can be many MVCs within one application, each communicating with each other.

What’s the responsibility of this object?