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 ?
Asked
Active
Viewed 1.5k times
51
-
17People like to every now and then rename things and think they just came up with a brand new idea. Take the [FLUX architecture diagram](https://facebook.github.io/flux/docs/overview.html#structure-and-data-flow) for example, if you replace Dispatcher with Controller and Store with Model, what do you get? – pgpb.padilla Feb 14 '16 at 22:00
-
2just to look a bit into details such an architecture was very well described in [GUI Arcitectures](http://www.martinfowler.com/eaaDev/uiArchs.html#Model-view-presentermvp) article by Martin Fowler – xmike Nov 09 '16 at 08:18
-
https://www.infoq.com/articles/no-more-mvc-frameworks – Brian Cannard May 17 '17 at 05:47
4 Answers
43
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.
Arun Kandregula
- 655
- 3
- 8
- 18
18
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.
chugadie
- 2,786
- 1
- 24
- 33
-
You can use below equation for Bi-directional and uni-directional: 1) Controller -> View 2) Controller -> Model 3) View <=> Model – Siddiqui Nov 24 '16 at 10:45
17
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 | |
| | | | | | |
|------| |------------| |-------| |
| | | |
| |--------------------<<<<-------------------| |
|----------------------<<<<----------------------------|
user12345
- 661
- 8
- 34
-
3What you call 'Traditional MVC' is an Application Model or MVP and 'FLUX' is classical MVC https://www.martinfowler.com/eaaDev/uiArchs.html#ModelViewController – maksimr Aug 10 '17 at 12:10
-
7Was it hard to type this model by keyboard? Or did you use a generator, or tool? – Teoman shipahi Feb 18 '18 at 03:45
6
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
Looks like your programmers created flux because they didn't know how to properly use MVC and event dispatchers.
Alasdair McLeay
- 2,572
- 4
- 27
- 50