MVC and MVVM are two initialisms used to describe the architectures of software projects. The initialisms stand for Model-View-Controller and Modal-View-ViewModel, respectively. I find it useful to define these parts as:

• Model – code that cares about how data is stored
• View – code that cares about how data is displayed
• Controller – code that cares about how data is created/updated/deleted
• ViewModel – code that cares both about how data is stored and how it is displayed

From just looking at their names, it appears that the main difference between MVC and MVVM is that a Controller is replaced with a ViewModel. This idea is false, and is the result of unfortunate naming.

Both MVC and MVVM architectures contain a Controller piece. In fact, every software project has a Controller piece, since every software project manipulates data.

Both MVC and MVVM architectures contain a ViewModel piece, as well, since both architectures require data to be mapped from a Model to a View.

The core difference between the two architectures lies in the richness and complexity of the ViewModel.

In a more MVC project, the ViewModel is next to nothing. All the client sees is a stateless View that’s had data mapped to it from the Controller by the ViewModel. If the client wants to see different data, or to temporarily manipulate the data it sees, the View must send a new request to the Controller. As an example, ASP.NET and WordPress projects tend to fall under this category.

In a more MVVM project, the ViewModel is substantial. It keeps track of its own internal state, i.e. the client can perform temporary data manipulations that don’t get communicated to the Controller. As an example, React and Angular projects tend to fall under this category.

As a final note, these labels should be used only as long as they are useful. In the messy real world, no piece of software is completely MVC or MVVM; shades of grey always exist. It is important to ensure that your team attaches the same concepts to the same words, yes, but it is also not your end goal. Our mission as developers is to create useful and maintainable tools, not to argue over which labels to attach to our projects. If you find that your project doesn’t cleanly fall under one of these labels, go ahead and make up your own.

Happy hacking!