MVC & MVVM

After suffering the pains of monoliths, MVC came to save the day and MVVM was later born to stand on its shoulders.

Model-View-Controller

In 1979, Trygve Reenskaug came up with this architecture as a way to solve the issues related with writing code in a monolithic structure.

This was a fine attempt at ‘separation of concerns’ and was guided by the following logic: Don’t entangle what you are working with, what you are trying to do with it and how you want the result to look.

More accurately, it contemplated three basic units (or layers):

• Model: The business entities/logic.
• View: The UI (or rather a single aspect or portion of it).
• Controller: The ‘procedural’ or ‘application’ logic. It would guide all interactions between the two.

If done right you would end up with multiple View-Controller pairs per screen, since each view should only be responsible for a single piece of the UI (widget, button, text field…) and talk to a Controller if data was needed. This also means that if multiple Views needed the same data, they would communicate with the same Controller.

Notice here that the Controller reacts to the View, and manipulates the Model as a consequence. The View would then react directly to the events triggered by the Model, updating the UI accordingly.

This forces a one directional flow in which the user interaction with the View determines what a specific Controller should do with the Models, which in turn updates the View directly. So no Controller is needed on the way back to the View.

This design is often still used in the front end (which is no surprise since it was created in the context of GUI reliant desktop applications).

This approach leaves us with a couple of issues:

1. Having multiple View-Controller couples per screen can get messy fast.
2. Having multiple Views per Controller can get even messier (remember, we are talking about each button, label, etc.).
3. Having the view use the Model objects directly is a source of coupling.

You could just smack another Controller into the mix and call it a day or force the execution to make another stop at the same one on its way out. You could go all the way and update the architecture all together (of course changing the name in the process, developers love renaming things).

Model-View-ViewModel

That’s exactly what John Gossman thought around 2005.

Basically, he called the old Controller ViewModel and made it also responsible for the events fired by the Model. So now, the flow of execution would stop in the ViewModel both on its way to the Model and on its way back to the View.

This new and improved ‘Controller’ now had the power to manipulate Models as well as to implement View specific logic (which made the View much simpler for designers to focus on design). Now View and ViewModel must have a 1:1 relation.

This is a much up-to-date approach. Remember, MVC was created before HTTP.

As you might imagine, once the Model operations get complicated and/or there’s a bunch of different data to manage or present together, It’s hard to keep each concern properly separated.

Mister Jackobson would like a word.