Flux vs. MVC: Comparing two Application Design Patterns

Do I have to master yet another architectural pattern? I was just getting pro in MVC!

Well, you may have this quandary if you have already heard about the Flux design/architecture pattern from Facebook, and what it does. In this article, we will compare the MVC architecture with Flux from various perspectives.

Let’s dig in!

Are you keeping up with new developer technologies? Advance your IT career with our Free Developer magazines covering C#, Patterns, .NET Core, MVC, Azure, Angular, React, and more. Subscribe to the DotNetCurry (DNC) Magazine for FREE and download all previous, current and upcoming editions.

MVC vs Flux - Introduction

Unless you have been hiding under a rock and are not a web application developer, I believe you have had some experience (or familiarity) with the MVC architecture.

Historically, there has been a lot of MVC patterns, followed across various technologies including ASP.NET, PHP, Ruby on Rails, various JavaScript frameworks, as well as libraries. While it is a popular architecture for web applications, you also have some thick client technologies like WPF follow a variation of MVC a.k.a. the MVVM pattern.

Flux is a new application architecture introduced by Facebook in May 2014. The team at Facebook stated that it was designed by Facebook to overcome the limitations of MVC architecture.

We’ll see how!

MVC Popularity

MVC is a popular and widely-used architecture for developing web applications.

MVC based apps span across various verticals like Business, Shopping, Education, Government, Health etc. The MVC architecture is widely popular across different technologies like ASP.NET MVC, PHP, RoR as well as any other frameworks or technologies that use the MVC architecture.

In this context, it is fair to suggest that the MVC architecture is the de-facto architecture used in modern web application development, irrespective of the technology.

A Two-minute Primer on MVC

MVC is based on SoC (Separation of Concerns) principle.

It essentially means that you separate out each concern (or responsibility) in such a way that each component addresses a specific concern (or responsibility) in a modular fashion.

Source: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

I am assuming that you must have already seen this diagram umpteen times and have a good understanding of the functioning of MVC architecture. Hence I would not be focusing my efforts on explaining all the aspects depicted in the picture above.

Editorial Note: If you are new to MVC or ASP.NET MVC, check this - www.dotnetcurry.com/aspnet-mvc/922/aspnet-mvc-pattern-tutorial-fundamentals

“Patterns are awesome; developers aren’t?” – Model View Confusion?

Usually, the concept or architecture is not the culprit; it is the use (or overuse or wrong use) of the architecture to solve business problems, that creates issues.

Let’s look at some key aspects of what led to the perception that MVC architecture has problems (please do note the word “perception” here):

Bidirectional vs. unidirectional data flow: MVC design pattern itself does not put any constraint when it comes to flow of direction of data between Model, View and Controller.

In MVC, as you know, the Model is responsible for managing and maintaining the state of data and the controller does the job of data updates based on user interactions in the View. So, the controller maintains application state and also mediates between Model and View.

This gets really difficult to manage in complex applications and hence two-way data binding works well in cases where quicker updates are to be made to the Model and View, based on user interactions. In fact, two-way data binding is widely used in many JavaScript frameworks, including Angular. So, anybody’s claim that bidirectional data flow in MVC is an issue does not make MVC a flawed pattern.

Flux, as an architecture or pattern, now has a built-in structure that mandates unidirectional flow. The argument in favor of unidirectional data flow is that it promotes a clean data flow architecture. This ensures that data flows in your app in a single direction giving you better control over it. It also promotes loose coupling since the state of the application is contained in specific stores.

MVC creates too many Controllers and/or Views: Usually any MVC architecture implementation would have multiple Controllers.

So, if you have a complex application built using MVC, it is evident that you may end up with as many Views and Controllers, as the functionalities you have. And *that* could create a problem when many Views and Controllers interact with each other.

However, the pattern does not mandate you to have one Controller per View.

You can logically group together some controllers and optimize the code structure complexity accordingly. MVC does not mandate any notion of One Model > One View > One Controller structure. As long as each component is managing the SoC as per design principles, you can have logical collection of Controllers, Models and even Views.

For example, if you have a View that displays data from the User Profile and Shopping Cart model, then you can do this using the ViewModel pattern. The ViewModel in this context will be used to compose multiple models into a single one that be consumed by the View. Here is a link that explains some more ways of achieving this.

So, perceiving that the MVC architecture results into a complicated MVC structure, is incorrect.

MVC does not scale: (the scaling myth):

It is often mentioned that an MVC based application has issues with scaling.

While an architecture may be partly responsible for scaling related limitations, it is not the only factor. There are many web applications that are developed using the MVC architecture and are proven to be scalable to meet customer demands.

Having said that, information is the most challenging aspect of a software when it comes to scaling. Flux tackles information scaling well, as it puts information first and foremost, above everything else.

Let's get Flux'ed

Before we begin, let’s get de-MVC’ed first and look at Flux as a new architecture.

By this, I mean that we should leave all the MV-Confusion out and look at Flux with a clean-slate.

The dictionary definition of the word “flux” is the act/action of flowing or moving. The essence of Flux as an architecture lies in the flow of information in an application.

The Flux architecture has the following components:

1) Action: Action is raised by the View when the user interacts with the UI controls in the View.

2) Dispatcher: It holds the context to data store (or stores) and propagates the action from View to Store(s). Dispatcher would receive the Action from the View and would notify the Store.

3) Store: Store is registered with Dispatcher. Store contains the data. It receives an update event from Dispatcher and will respond to it. The response would be another “change” event (this is not the same event as the dispatcher event) raised to which the View is subscribed.

4) View: View would respond to the change event and would make appropriate changes.

The following diagram explains the architecture through a very simple example of a button being clicked on the View (or a web page) and how the various components of the Flux architecture handle this scenario.

Here are some key aspects to remember:

1) The Dispatcher is an event hub for the View. It handles all the Actions and calls the appropriate callbacks registered by Store(s) . So, View has an Action Creator that “creates” Actions. Since the View has frequent interactions with user which would result in a repetitive process of creation of Actions/events that are sent to Dispatcher; Action Creator provides required abstraction to handle this aspect more elegantly. Different flavors of Flux architecture have Dispatcher implemented in different ways.

2) Store needs to register with Dispatcher to get updates on Actions.

3) Dispatcher is more like a router for routing Actions to Store.

4) Store has data and would process it based on Actions received. So, Store is not the same as Model in MVC. It can contain models though. This is also the only component in Flux architecture that knows how to update data. This is where the business logic resides.

5) Store itself would raise events to update View based on Actions.

6) View renders itself again after the change event is raised by Store.

Some important aspects to note in context of MVC pattern:

1) Dispatcher is not the same as Controller. Controller is responsible for the communication between View and Model. Dispatcher is only responsible for handling Actions raised by View in the Flux pattern and inform the Store about the same (so essentially one-way communication). Store, in turn, would raise an event so that View is updated.

2) Controller plays a key role in MVC as it is the hub for essentially managing communications both ways. Due to the very nature of Flux pattern being unidirectional, this flow is managed through following chain of actions: Action > Dispatcher > Store > View.

3) With more Views and Controllers getting added, MVC could create a complicated flow of information. In case of Flux, as the application grows, there will be more Views added – and so will be more Stores. View will continue to raise Action that will be sent to Dispatcher. Dispatcher will then invoke the Store(s) that are registered for that action and that will invoke the right View. That is how Flux is Flex (flexible) also.

In a nutshell, Flux, by design, mandates the separation of concern principles in a more stringent manner through unidirectional flow and hence being more stringent in structure.

Please use this link for a simple demo elaborating the Flex architecture.

Flux-based JavaScript Frameworks – Flux vs Reflux vs Redux vs Alt vs Flummox

There are various Flux-architecture based JavaScript implementations that you can explore and decide to use the right one based on your requirements. Here is a quick table summarizing various Flux-based frameworks:

There are quite a few Flux based JS frameworks that you would find. Currently there is a lot of hype and discussion around Flux as a design pattern and hence there are a lot of new JS frameworks following this pattern that are popping up. The action is supposed to continue like this for a while until, as usual, some clear winners emerge in terms of reliability, extendibility and robustness etc.

Facebook's own Flux-based JavaScript framework would, undoubtedly, be the front-runner.

Editorial Note: To understand the difference between Flux, Reflux and Redux, check this https://stackoverflow.com/questions/32461229/why-use-redux-over-facebook-flux/32920459#32920459

https://npmcompare.com/compare/flux,redux,redux-saga,reflux

When Should I consider using Flux-based Design for UI?

Obviously, there is absolutely no need to change or re-architect any of your MVC-based applications.

Don’t fix it (or Flux it) if it ain’t broken!

For new web application development, you can think of using Flux-based development since it provides a clean design pattern to follow.

However, do keep the following things in mind:

• Learning curve: Given that you are working with a specific design philosophy (Flux), you will need to ensure that you understand the concepts well before writing any Flux-based JavaScript Framework. As I said before, a pattern is as good as how it is implemented.
• UI Complexity: You will need to ascertain if the use of Flux architecture is going to help the cause. Would you rather go with a React JS implementation for a simple functional UI with minimal complexity, or would you need Flux to handle various intense interactions that are mandated by the kind of application you are building.
• Choice of Flux framework: There are quite a few frameworks already. You will need to choose the one that suits well for your needs.

These are of course some factors that you ought to consider. Additionally, it would be useful to get your hands dirty by playing around with readily available samples/demos so that you can get a real taste of usefulness of the Flux-based frameworks (as against MVC-based frameworks).

Seeing is believing!

Conclusion:

Are you flummoxed by Flux yet? Or are you still held up with the Model-View-Confusion?

Well, whichever state you are in, it is evident that Flux architecture based JavaScript framework is another step taken towards building efficient and clean web applications.

It can be looked upon as an attempt of applying the learning from MVC-based JavaScript web development and building something that can withstand ever-growing expectations from various stakeholders for building rich UI web applications.

With the rapid pace at which JavaScript ecosystem has evolved and is evolving, I wouldn’t be surprised if there is yet another design pattern (eg: redux or similar) that is just around the corner. So, the flux continues…

This article was technically reviewed by Damir Arh, Yacoub Massad and Suprotim Agarwal.

This article has been editorially reviewed by Suprotim Agarwal.

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

Author

Rahul Sahasrabuddhe has been working on Microsoft Technologies since two decades and leads Microsoft Technology Practice at a leading software company in Pune. He has been instrumental in setting up competencies around Azure, SharePoint and various other Microsoft Technologies. Being an avid reader, he likes to keep himself abreast with cutting edge technology changes & advances.