Breaking Down MVC and Flux Architecture
In web development, you might have heard of MVC and Flux architecture. MVC and Flux are two architectural patterns most applications use. It is important to know these patterns, because it decides the foundation of how a business or customers fulfills its needs in the application. By breaking down the differences between the MVC and flux, we can understand the high-level overview of how our applications operate.
MVC is an architectural pattern frequently used in the industry for creating scalable applications. MVC stands for Model, View, and Controller, and each component has a specific task.
Model: Handles anything data-related. This can be data transferred from the View or Controller. For example, the data can be users' information we fetch from the database.
View: The user interfaces the user interacts with. It is the client with the navigation bar, dropdowns, inputs, and more. It is basically a “dummy” component that shows the user data.
Controller: Acts as the “glue” between the Model and View that handles all the traffic. It will handle all the logic and manipulate the data using the Model component and render it on the client with the View component.
It’s important to understand MVC architectural patterns because not only is it prevalent in the industry, but it is to ensure your code is stable through the separation of concerns. By separating the logic into separate parts, you can continually add more code, unit test, and isolate any areas of concern. An example of a frontend framework using the MVC pattern was Angular (before shifting to MVVM in Angular 2).
What are the benefits of MVC?
- Fast Development: Supports rapid and parallel development. One engineer can work on the view and another can work on the controller.
- Multiple Views for Model: Helpful for developing multiple views as demand for accessing web applications increases.
- Modification Does Not Affect the Entire Model: Adding features or making adjustments such as changing the layout or font colors does not affect the components because they are segregated.
- Returns Data without Formatting: Any component can be used and called with an interface due to the flexibility of working with the data.
Flux is an architectural pattern originated by Facebook with the introduction of React. Flux architecture is primarily used when building out client-side web applications. Unsurprisingly, this architectural pattern complements React with its concept of unidirectional data flow which is the central feature of Flux.
Flux is broken down into actions, dispatcher, store, and controller views.
Action: A plain object that contains information to perform any changes. Typically, an action contains a type property to denote what type of action it is.
Dispatcher: Receives actions and broadcasts the event/payload to registered stores. When an action is executed, the action will be passed to the store.
Store: Container for application state which includes the domain state and user interface state. It will listen for actions and perform logic in the state. The store is essentially an event emitter because any executed action will emit a change event.
View: User interface components that grab the state from the store and pass it down as props to children components. They are listening for store changes and re-renders.
What are the benefits of Flux?
There are more parts in Flux than MVC, but the idea is to have a streamlined approach. Even as the applications get more complex, ease of use stays the same. The unilateral movement ensures there are no ambiguities in the relationship between the components. Additionally, Flux better handles applications that don't have views that map to the domain store. Views create actions that will update many stores and stores can trigger changes that will update many views. The actions can be persisted and replayed.
If you are working in web development, you might already be working with Flux architecture due to React's sheer popularity in the frontend world. It is good to understand MVC architecture, because it is foundational knowledge that has been around for a long time. There are a ton of applications and projects that utilize the MVC approach. Both are relatively easy to understand and every engineer should be able to highlight the overall structural patterns. If you're in the job market, you might even be asked to describe the differences like I did. Hopefully, my article can help you when that time comes!