I read a post on reddit about MVVM vs MVC, and it’s a common debate, so I thought I’d chime in with my own opinions.

The crux of it is that most people think that these letters mean the classes in your application. In all but the most trivial of applications, those people are wrong. If you have one “data” class, and one “view”, then, sure, MVC means you have a Model class, a View class, and a Controller class. And, maybe a bunch of them for each view. Sure, this is how you explain it in a tutorial, but the real world is not a tutorial. When things grow, they think, “Too much of my view is creeping into my model! What a bad design MVC is!”, and then the create a ViewModel.

NO NO NO. These are concepts, not classes. MVC is an architecture pattern. MVVM is a design pattern (and, often considered an anti-pattern). What’s the difference? An architecture pattern is a high level design whereas design patterns are generally, a way to organize a class or two.

What MVC really means

Your Model is, perhaps, a database, represented by some classes that access that database. (Or, just some stuff in memory. Or some prims on a scene.) The point is, that these know nothing about how they are presented. Just data.

Your Controller is something that might handle creating the model. Say, you might get data from a database or from the “cloud”. Your Controller isn’t a class. It instantiates a class (that probably lives in the conceptual Controller grouping, but that’s up to you) to create some “model” concept.

Your view is probably not something you’d write or even subclass. But it’s not a UITableView or QTextView or whatever. It’s the GUI. Luckily, this is kind of impossible to do, since your GUI is hardly ever just one class.

What MVVM will get you

The problem when someone sees MVC is that they think it’s 3 classes. The problem with MVVM is that, well, it’s literally 4 classes (because Xcode will generate a ViewController for you). MVC was not supposed to be taken literally, whereas MVVM (plus Xcode’s C) is actually supposed to be a set of literal classes.

What real design means

Real design isn’t creating a bunch of classes for each view in your IDE. It’s creating a data model with some forethought. And a real controller where you handle instantiating the model, and feeding pieces of data from the model to the parts of the view that present that data. Perhaps you have a presentation of that view that you might call “ViewModel” classes. That’s fine. But don’t think you’re revolutionary to think you’ve reinvented a new programming paradigm.


When we’ve spent almost 40 years with a concept, if you think something is wrong with it in building your little app, don’t immediately assume that the paradigm has a problem. MVC has been used for projects a whole hell of a lot bigger than yours by programmers with a lot more experience than you. Go ahead and question things, but be humble enough not think that software development has been broken for 40 years and your idea is the one that will fix it.

This sort of goes for Object-Oriented programming, and, of course, now, functional programming. Obviously, language support makes it easier and better, but I’ve done both OO and functional programming in C. They’re ugly and awkward, and I love that modern languages support these concepts. But, usually, modern languages make it safer and easier to do some fancy concept that new languages have special (and better) syntax for something that’s been around for decades.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.