Today Model View Controller (MVC) is considered the most spread application design pattern in web development. Since the 1990s, if you wonder. And Flux is a new application architecture from Facebook that promises the same as MVC, but with a different approach that focuses on unidirectional data flow. What application is better? Let’s make a comparison: Flux vs. MVC.
Both of these two design patterns can be applied to your web project, but to find out which is better we suggest you learn more about MVC and Flux. Both are software design patterns that help developers write clean, maintainable, code.
We’ll start with MVC
Despite numerous updates and implementations since MVC was launched, its main concerns stay unchanged:
- Model: The data or state of your application, which is independent of the controller or view
- View: The UI logic that represents and displays the data (model)
- Controller: The logic that links the model to the view and external inputs from a user.
In MVC, it’s the controller that manipulates the data in the model and updates the view, often in response to inputs from the user:
MVC can be interpreted or modified in many ways to fit a particular framework or library. For example, Backbone.js subtracts the controller for a lightweight MV paradigm. Some of the more traditional MVC-based frameworks include AngularJS and Ember, and let’s not forget that where this design pattern really thrives—the back-end, with server-side frameworks like ExpressJS.
The core ideas of MVC can be formulated as:
- Separating the presentation from the model: enables implementation of different UIs and better testability
- Separating the controller from the view: most useful with web interfaces and not commonly used in most GUI frameworks
In general, MVC makes no assumptions about whether data flow within an application should be unidirectional or bidirectional. That doesn’t matter until your codebase starts to scale. For this purpose Facebook created Flux. By forcing an unidirectional flow of data between a system’s components Flux is making the solution.
And here the Flux features come
Flux places unidirectional data flow front and center, by making it a requirement. Here are the four major roles that make up the Flux architecture:
- Actions, which are helper methods that relay information to the dispatcher
- Stores are similar to the models in MVC, except they act as containers for application state and logic for a particular domain within the application
- The Dispatcher receives Actions and acts as the sole registry of callbacks to all stores within an application. It also manages the dependencies between stores
- Views are the same as the view in MVC, except in the context of React and Flux, and also include Controller-Views for change events and retrieve application state from stores as required.
How it works?
- All data in the application flow through a central hub called the Dispatcher
- This data is tracked as actions, which are provided to the dispatcher in an action creator method, often as a result of a user interacting with the view
- The dispatcher invokes the registered callback, effectively dispatching the action to all stores that have registered with that callback
- The stores in turn relay that change event to the controller-views to alert them of the change
- The controller-views listen for events, retrieve data from the appropriate stores as required and re-render themselves and all their children in the component tree accordingly.
Bad points of Flux: you always need to know about the actions which are already there. Actions are the main bridge of communication in this architecture and you can’t really duplicate them. You always have to know about already registered actions, and that’s painful.
But still, can we take Flux instead MVC for our next web project?
It depends on technologies you work with, the aim of your website or web application and the paradigm you prefer to use.
Flux was made for React, and its emphasis on unidirectional data flow is particularly useful for component-based web development—that means frameworks and libraries like Vue.js, Angular 2, and Polymer can all find a natural synergy with Flux, and it’s why you can already find support for implementing this new architecture with these frameworks.
MVC has been around for a long time, and there’s no shortage of frameworks that can help you build with MVC—AngularJS, Ember, Sprout, Backbone, and Knockout are just some of the examples on the front-end. If you’re using PHP, probably, you’re also using MVC. The MVC architecture really shines on the backend, where the entire client-side can be thought of as the view. This is in contrast to Flux, which is largely a front-end pattern that solves the issue of managing application state on the client-side. The MVC pattern can be found on most back-end frameworks or solutions—including Express, Django, Ruby on Rails, Meteor, Spring etc.
Compare them with the help of this neat table:
|Bidirectional data flow||Unidirectional data flow|
|Data binding is the key||Events or actions are the main players|
|Controllers handle the business logic||Store does all calculations|
|Somewhat synchronous||Can be implemented as completely asynchronous|
|A trusted architecture used by a lot of companies in a lot of projects||Helpes to solve complex problems which MVC couldn’t|
As always, the decision is up to you. Consider all the points and take what fits best your project. Or ask us for advice.