MVC is an acronym that’s commonly asked on interviews for full stack development or general software engineers positions. Chances are, you have been asked this question before:
What is MVC?
Hopefully, some of you reading this out there even know what it means!
Model-view-controller is a standard convention across large codebases, a pattern used on several teams across the world. Developers and engineers working on user-facing projects are indoctrinated with MVC.
But, does MVC matter? That’s the question.
In some languages, MVC is a moot point
In certain programming languages, there is no such thing as MVC. It is either a debatable question for some programmers or an altogether irrelevant question, a matter of no importance.
To rephrase, certain languages have no concept of a “view”, or a “model”, or a “controller”, resulting in a half-finished software design pattern.
Aside from language restrictions or usefulness, certain applications themselves may not require the convention of MVC. Regardless of this, I think MVC is still useful in certain situations, but first, we will examine a few common application environments.
MVC: in browsers (SPAs)
With the advent of React, Angular, and Vue, MVC’s worth as a design pattern vastly diminished.
For instance, let’s consider a typical React application. What would you classify as the model? The view? The controller?
In most cases, the view is your React component. The controller is missing. A model is hard to pinpoint, but “follow the data” and you might find one.
Optionally, if you are using something like Redux, designating MVC pieces becomes much easier.
Reducers in Redux work in a similar fashion to a controller. Reducers mutate and modify the underlying model within an event-based system — it’s essentially a giant pseudo-state-machine.
Redux utilizes reducers as mediators that react to the changes in the state to help your components update. Together, this setup actually shares a lot with PureMVC, which ironically doesn’t strictly need model-view-controller either.
MVC: in video games
Another common application where model-view-controller does not make sense is a typical video game.
You may have a model somewhere, perhaps character information stored in a database or game saves stored in a filesystem. You will probably have a controller, like the code to control a character or action, but they’re not the same controllers that we use as a web developer.
On this front, another thing seemingly replacing MVC are systems such as GraphQL or Falcor.
With these implementations, you return JSON or XML, another view of your content. With MVC sometimes people incorrectly think that the “V”, the view, is always going to be HTML or UI components. That’s not true.
In my opinion, XML, JSON, CSV, and other file containers are considered a view. They’re exactly the same thing as HTML — a script or markup type language; they structure content, but they aren’t designed to show content to end-users. They show the content much like HTML does — if you were to look at XML or JSON code raw, you would still be able to comprehend the content. HTML is different because of a browser, which will make it look nicer.
With things like GraphQL and Falcor, JSON replaces the view. This is still MVC.
MVC does still matter
Again, regardless of whether you are using Rest APIs, GraphQL, Web Sockets, you’re still using some form of MVC, whether you call it model-view-controller or not. You may use MVC already.
As part of a healthy team of like-minded developers, use the words model, view, controller as you see fit, and be wary of trying to make new naming schemes or conventions where you slap a new coat of paint onto MVC terminology. Now go forth and argue about the merits of MVC, MVVM, MVP, AVP, MVC2, and CPM.
Originally published at hyperpolyglot.io on November 27, 2018.