MVVM is Not Good and Not MVVM is Good

Last week, Soroush Khanlou published “MVVM is Not Very Good,” wherein he describes the “Model-View-ViewModel” pattern as the iOS Community defines it, and considers it:

an anti-pattern that confuses rather than clarifies. View models are poorly-named and serve as only a stopgap in the road to better architecture. Our community would be better served moving on from the pattern.

Today, Ash Furrow published his thoughts on the matter in “MVVM is Exceptionally OK,” wherein he agrees with the main tenets of Soroush’s article, and suggests some modifications to the pattern:

MVVM is poorly named. Why don’t we rename it? Great idea. MVVM is a pretty big “umbrella term”, and precise language would help beginners get started.

Both articles, I think, are really arguing the same things, but maybe from different directions:

  1. Plain old MVC is leads to huge, disorganized, unmaintainable code (most of it in a UIViewController).
  2. We need better ways of organizing our code.
  3. MVVM, as the iOS Community interprets it, is not really good enough.

Of the defences I’ve seen for MVVM, almost all of them suggest with some tweaks, MVVM is actually a good thing. I think, broadly, this is true, but you can’t really change MVVM without it becoming something that is no longer MVVM; the original MVVM remains, as Soroush argued, “not very good.”

What’s important to remember is the point of things like MVC and MVVM in the first place. In our industry we tend to call these patterns, but I prefer to call them perspectives: they are mental tools which allow you to see a problem from a different point of view. It’s the old “when all you have is a hammer, everything looks like a nail” routine, where the joke is your hammer is the only perspective you have on the world. The solution to seeing everything through the eyes of a hammer isn’t to start seeing everything through the eyes of a screwdriver, or a paintbrush, but instead to see things from many perspectives.

Programming is a dark goop, hard to see under just one light. But from that goop also emerge new ways to see. Every time you form a new abstraction, no matter how small the method or how collosal the class, you build for yourself a new point of view.

MVC and MVVM are but two narrow views on what we know as programming, a confusing mess in desperate need of more light.

Speed of Light