Stop calling MVVM an architecture
It may even have some positive impact on your codebase
MVVM and it’s bit more advanced version – MVVM+C are very popular ways to build modern iOS apps. And that’s a good thing – I’m also using it, I can say I like it, and most implementations I’ve seen so far are better than most basic approach in iOS world – MVC (and you know what I mean).
But there is one thing I do not really like about MVVM – it’s when people are calling it an architecture. Let me explain why.
MVVM in action
So the thing about MVVM is that it describes how your view layer is working. You have a ViewModel, which is kind of brain of your visual layer, driving the View and taking all the user’s inputs from it. The ViewModel knows what to do with inputs and passes it to.. ok stop here for a minute.
The M
The M states for the Model. What’s the first thing you have in your mind when someone is saying: a model. For me most of the time it’s some kind of data. Not a business logic, not a database, not a networking, not a fancy class doing fancy things. That’s somehow an issue when calling MVVM an architecture — it does not answer about all that important stuff. In MVVM developers often treats M like all the rest of the app that ViewModels needs to communicate with. And when you think about that, that sounds as an easy way to end up with a Massive ViewController’s alter ego – the Massive ViewModel.
What is the MVVM then?
It’s a design pattern that describes how your app’s view layer is build. A very nice one – I really do recommend. But not an architecture.
What architecture do I use?
For me personaly that is a hard question, and I don’t have an one word answer, or any descriptive name to call an architecture that I was using in my last projects.
So if someone would ask me: what architecture was used in the app you recently worked on? I would tell, that I was trying to follow rules from Domain Driven Design, Clean and SOLID. I would talk about layers, starting from Domain, telling how and where business logic is implemented (and yes — not in a ViewModel). I would describe how the App is doing networking and storage. I would mention about Dependency Injection, and how nicely it plays with modularity. And yes, I would definitely tell about MVVM and Coordinators, as design patterns used in a view layer.
I think that what the architecture is mostly about – layers and how they interact with each other. In this scenario, MVVM is only one of those layers.
The positive impact and final thoughts
So what is the positive impact if you stop calling MVVM an architecture?
Well, naming things won’t change much, but the way we think about different concepts when writing code daily might. For me, the most important thought I wanted to share is following:
Remember, that your app is much more than a view. Do not let that Model inside MVVM to grow, and define proper layers for it.
And that’s it!
Please clap if you liked that article, and if you don’t agree or have a different view on that topic leave me a comment. Thanks for reading!
