MVC vs. Flux ? Bidirectional vs. Unidirectional?

Model View-Controller Problem Overview

Looking at the following diagram (which explains MVC), I see unidirectional data flow.

So why do we consider MVC to have bidirectional data flow while justifying Flux ?

Model View-Controller Solutions

Solution 1 - Model View-Controller

Real and Pure MVC is unidirectional. It is clear from the the wikipedia diagram pasted in the question.

More than a decade ago, when server side frameworks like Apache Struts implemented a variant of MVC called Model View Presenter (MVP) pattern, they made every request go through controller and every response come back through controller. Everyone continued calling it MVC. Due to inherent nature of the web, any changes in the model cannot be propagated to the view without view sending a request or update. So Pure MVC is not implemented. Rather MVP is implemented.

Few years back, when frameworks like Angular, Ember, Knockout implemented MVC on front end, they implemented another variant of MVC called Model View ViewModel (MVVM) pattern, few folks continued called it MVC. (and few realized that terminology is not important and called it MVW (W stands for Whatever)), none of them implemented pure MVC.

When React was born, they took the opportunity to implement pure MVC (not MVP or MVVM), and renamed it as Flux with few changes. I feel Flux is one more variant of MVC. Although, Flux/React team says it is not MVC, I see lot of parity between both the architectures - Flux and MVC.

Solution 2 - Model View-Controller

Because in Javascript frameworks the MVC does not work the way you depicted. The UI generally communicates bi-directionally with the model, as in:

User types into View input
MVC framework binds onchange() to update a model.
Ajax request brings in new model data.
MVC framework updates View input's value to match model.

In Flux architecture, the UI would only fire an independent action with type and associated data to a dispatcher which would then update the model the same way any background ajax method would update the model.

Reference: http://www.thesoftwaresimpleton.com/blog/2013/03/23/client-side-mvc/

> "Client Side MVC is completely different than Server Side MVC" > > "We are setting up a two way communication between two objects..." > > "In short we are wiring together the value of the firstName property > of the Person object to the value property of the input."

http://guides.emberjs.com/v1.10.0/object-model/bindings/

> bindings in Ember.js can be used with any object, not just between > views and models.

Solution 3 - Model View-Controller

I am an embedded developer and I use MVC pattern in my application. My application is very small and I have set up my architecture to be almost unidirectional MVC. But, I read this article, explaining client side MVC, and some thoughts about differences between MVC and FLUX.

Reference: http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MVC-and-FLUX-wrong

Traditional MVC

|------|  request   |------------|  request   |-------|
|      | ---------> |            | ---------> |       |
| VIEW |  response  |            |  response  |       |
|      | <--------- |            | <--------- |       |
|------|            |            |            |       |
                    | CONTROLLER |            | MODEL |
|------|  request   |            |  request   |       |
|      | ---------> |            | ---------> |       |
| VIEW |  response  |            |  response  |       |
|      | <--------- |            | <--------- |       |
|------|            |------------|            |-------|

FLUX

 COMPONENTS          ACTION CREATORS           STORES

    |----------------------<<<<-------------------|
    |                                             |
|------|            |------------|            |-------|
|      |  request   |            |  request   |       |
| VIEW | ---------> |            | ---------> | MODEL |----
|      |            |            |            |       |   |
|------|            |            |            |-------|   |
                    | CONTROLLER |                        |
|------|            |            |            |-------|   |
|      |  request   |            |  request   |       |   |
| VIEW | ---------> |            | ---------> | MODEL |   |
|      |            |            |            |       |   |
|------|            |------------|            |-------|   |
   | |                                           |        |
   | |--------------------<<<<-------------------|        |
   |----------------------<<<<----------------------------|

Solution 4 - Model View-Controller

Some people adopted the term MVC to refer to JavaScript frameworks that others had pointed out were not pure MVC but were a variation that could be referred to as MVP (Backbone), MVVM (Angular 1) or more broadly MV* (also see Arun's answer).

When Facebook introduced Flux, they compared it to the issues with MVVM/MVP/MV*, but confusingly used the term MVC.

To pure MVC developers watching this video, Facebook's stated issues with MVC did not make sense, and Facebook's description of Flux was closer to MVC than the MVVM system they described:

> The core problem is that they were "doing" MVC wrong. Then they fixed it, but decided to rebrand it and say they'd invented the pattern of decoupling data, view, and event handling

YouTube comment

> Looks like your programmers created flux because they didn't know how to properly use MVC and event dispatchers.