two fists in black boxing gloves

In one corner, we have MVC (Model View Controller), the reigning king in the realm of web development that’s been helping developers on their quest for “separation of concerns” since the 1990s. In the other corner we have Flux, a new application architecture from Facebook that promises the same, but with a different approach that focuses on unidirectional data flow. Both are software design patterns that help developers write clean, maintainable, code.

Read on to learn more about these two design patterns and learn which might be better suited for your next web project.

The MVC Design Pattern

MVC has been around for so long that there have been countless interpretations, spinoffs, and implementations, but the one thing they all have in common is the separation of concerns into three roles:

  • 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:

model view controller framework

In practice there are many ways that MVC can be interpreted or modified 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 Flux Design Pattern

In general, MVC makes no assumptions about whether data flow within an application should be unidirectional or bidirectional, which isn’t necessarily a problem until your codebase really starts to scale—Facebook realized this, and created Flux as a potential solution.

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, which listen for change events and retrieve application state from stores as required.

All data in the application flows 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. The simplicity of this approach is better appreciated in graphical form courtesy of the Flux development team:

Should I use Flux or MVC for my next Web Project?

It really boils down to the technologies you’re working with, what you’re building, and the paradigm you prefer to use.

Flux was made for React, and its emphasis on unidirectional data flow is particularly useful for components-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, chances are you’re using MVC.

It’s on the back-end, where the entire client-side can be thought of as the view, that’s where the MVC architecture really shines. 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, and Spring, just to name a few.

At the end of the day, the pattern you ultimately use tends to be a product of the technologies you choose to employ. Use the technologies that best suit your project’s needs.