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.
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 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.
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.
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.
1) Backed by Facebook. Has got great community support.
2) Multiple Stores per application but each Store is singleton.
3) Dispatcher is singleton.
1) A variation of Flux, since it does not have a Singleton Dispatcher.
2) Actions act like Dispatcher. And hence there are no Action Creators.
3) This is termed as a terse implementation of Flux due to absence Dispatcher and Action Creator etc. components.
1) Store does not contain change logic
2) Store is Singleton for an application
3) No dispatcher implementation. Store has Dispatcher built in.
1) Pure Flux implementation
1) Relatively new in the overall Flux-based JS Frameworks ecosystem.
3) Actions and Stores are created first and then they are brought into a Flux class so that you follow a Flux-architecture.
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.
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
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:
- 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!
Are you flummoxed by Flux yet? Or are you still held up with the Model-View-Confusion?
This article was technically reviewed by Damir Arh, Yacoub Massad and Suprotim Agarwal.