Is the MVVM Pattern an Architectural or an Design pattern?

Question

I've done some research about this topic and i already used the MVVM pattern in few applications.

I'm asking this question because sometimes MVVM is referred as a design and sometimes as an architectural pattern.

In most of the cases, the MVVM Pattern is called a design pattern. However personally I would vote for architectural because for me it clearly defines the architecture of an application (eg. three layer, View, ViewModel, Model and how they interact with each other)

This SO Question & Answer is about the difference between architectural and design pattern. In the answer it is said that MVC is a architectural pattern. Almost every explanation of MVVM contains a comparison with MVC. Is MVVM therefore also an architectural pattern?

This msdn article (which is btw very good) calls the MVVM Pattern a design pattern and is written by someone who really should know the difference.

I'm confused. Design or architectural pattern? is the term just mixed up?

EDIT: i need to know this for my bachelor thesis

Answer 1

I tend to think of architectural patterns as "decisions" with a lasting ramifications. They make up the skeleton of your application and so it is hard to get away from them.

For instance, a methodology for how to build your views is very hard to get away from, so I'd call it an architectural pattern. Microsoft designed ASP.NET WebForms to work a lot like WinForms. It was difficult to switch to a more MVVM approach mid-way through a project. Even choosing WebForms as your technology stack drastically affected what you could do with your application.

I think of design patterns as variants of an implementation - they can be used without impacting the rest of the application. You typically refactor to patterns, with the expectation that the code will change. To the point, design patterns are meant to help facilitate future change.

Obviously there is a fuzzy line between the two. Consider the repository pattern (typically considered an architectural pattern). It is really a facade (or proxy) to your data tier. Here, you pointing out a recurring use of a design pattern - elevating it to an architectural pattern - because it affects how you architect your system. You now have a rule: whenever I hit the database, I will do this, this and this.