Are MVC, MVP and MVVM really architectural patterns?

Short answer: no.

Behind the scenes

Once, we were discousing at company about mobile architecture, such as MVC, MVP and MVVM, and a colleague, Victor Caldas, said that they weren’t architectural patterns. Of course, I laughed at first, and then I made a polling with some mobile developers friends of ours and, of course, we win by far. Everyone said that MVC, MVP and MVVM were, undoubtedly, architectural patterns.

Some time after, I was working at a huge project which I was creating from scratch and I faced some situations that I tought that those ‘architectural patterns’ weren’t working nicely. This led me to think and I made some discoveries in my journey through the internet.

Why it’s not?

You , probably, will not find in the internet a reference to a blog or book that says MVC, MVP or MVVM are not architectural pattern (except for this post of Antonio Leiva); it’s the opposite: you will find everywhere in the internet that MV(something) is an architectural pattern and, whoever play with one of those, is an software architect. You, of course, will accept that, because it’s everywhere. It’s absolutely normal, and it’s not a critical mistake; but, it’s not the truth.

An architectural pattern is much more than a mere presentation-pattern , which is what MV(something) really is. Also, it’s not a ‘structure’ of the project, or whatever you call it. An architectural pattern include much more relevant and critical things than a presentation-pattern (the way you send your data to the views — be an activity or a fragment).

Thinking in the MVP world

For instance, let’s think about MVP pattern: you have a ‘model’ layer, a ‘view’ layer and a ‘presenter’ layer. In your ‘view’ package, you will have activities, fragments and adapters. In your presenter layer, you will have your presenters, of course. But, in your model layer, what will you have?

Short answer is: it depends.

You, of course, will have your entities classes. Maybe dozens of then. But that’s not enough on a modern application. You may have a class that manage if you have internet connection and fetch data from local database if you aren’t connected to the internet. You may have a class that cache data and a class that upload data to a server when the internet is back, or download data when the app open. That’s already A LOT of classes and callbacks and interactions between then and…

But, it’s not over.

You may have classes that not belong to model layer (dont belong to anything in MV(something) world), but, in some way, interacts directly with models, which are classes like a gpsManager, permissionsManager,sensorsManager,… and all the data they emmit will be sent to the model layer through the presenter, which, after, will store God knows where those data.

What I really want to say is that the ‘model’ layer is much more complex than it is threated when you simply say ‘I’am using MVP architectural pattern’. That’s not enough to describe what REALLY you is using in your app, once the ‘model’ layer is, sometimes, more complex than the presentation layer.
On the other hand, a presenter is simply a presenter: it format and presents data (which was received by model layer) to the view. The presenter have not enough responsability to someone say that this is an architectural pattern.

A new approach

I, humbly, propose a new separation of concerns on this topic, which is to split design patterns into three distinct groups.

First, we have design patterns that act on the very logic of the software (e.g. singleton, façade, builder, strategy etc). These, I call logical-patterns. They just receive data and process them. They can emmit or not data; it will depends on what pattern you is using.

Second, we have architectural patterns, which describes the software architecture that you are using. They are ideas to be implemented and not code templates like logical-patterns.

Third, we have patterns that act on the presentation of data of a software, like MVC, MVP and MVVM. These, I call presentation-patterns. They receive data from the model layer and format it in order to send to the view.

Some of you may disagree with my new proposition, and that’s ok. But, take a look at the definition of a design pattern, provided by wiki:

“…a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system

This description fits perfectly on what I’m proposing here, which is to split design patterns into three groups, and include the patterns know as ‘architecture’ (MVC, MVP and MVVM) into one of them.

In this context, you may ask which solution MVP, for instance, try to solve? It tries to solve organization and testability of the object that presents data, which is the presenter (which is hard to do on an activity, for instance). It has it’s own responsability, and it’s not to architect the whole project.


Some of you, dear readers, may be asking something like this:

“Wait. So, are you saying that those 'presentation patterns' aren’t architectural patterns? What are architectural patterns, so? Where are they?”

Of course there are architectural patterns. One of them is the well know Clean architecture.

Below there’s a list of some of them (this list can be found on Clean Architecture article right above):

If you are using one of those architectures, you can still use MVP or MVVM to present your data to the view, because they are (presentation)patterns, which make ‘smaller’ things and are ‘less important’, in the whole context, than an architecture. The fact is that an architecture theorize much more layers and responsabilies than a simple presentation-pattern, such as MVC, MVP or MVVM.

Thank you for reading and feel free to share your thoughts with the community!