In the beginning, there was MVC (Model-View-Controller) — for a long time the main pattern Apple and Google promoted in their tutorials for iOS and Android development. MVC was a good entry point for mobile developers, but one that came at a cost: a fixation on architectural patterns. Today, I want to encourage you to adopt a new way of thinking; one that delivers the benefits of architectural patterns without the bloat.
Following MVC’s arrival, the community moved forward quickly. MVP (Model-View-Presenter) appeared, trying to fix the "everything is inside of my controller" problem with MVC. At the same time, MVVM (Model-View-ViewModel) added the View Model to represent your View and its state.
This alphabet soup of new ideas and architectures then exploded: VIPER, MVC, MVI, VIP, ReSwift, just to name a few. Each proposing different ways to architect your app.
At the same time, the discussions in the mobile community became more vociferous: Is MVC wrong? Does MVVM lead to huge and unmaintainable ViewModels? Is VIPER a complex and overkill solution? Which is the best choice?
None of these discussions are invalid, but people tend to forget some crucial points:
"Model-View-Controller should mean massive view controller." And when it comes to view controller or activity, massive is a problem: it’s messy, complicated, unreadable and untestable.
But is all of this just down to MVC? I don't think so.
If you access your database directly from your activity, this is not MVC's fault. Are you making network calls from your view controller? That’s not MVC's fault either. Do you have to manage states in your fragment? Guess what? MVC is not the one to blame.
MVC means that your codebase will be structured around models, views, and controllers. It doesn't mean that everything must fit in one of these three boxes.
Let's take VIPER as another example. In this case, the acronym tells us that we should have a View, Interactor, Presenter, Entity, and (phew!) Router. But you probably will also need a database access layer, a network layer, GPS, disk persistence and so on.
Just like MVC, Viper is an architectural pattern that suggests entities around which you should architect your app. Again: it doesn't mean that you should fit everything inside of the proposed letters. You're free. Create as many layers as you need to keep your design consistent.
Can you have catastrophic results with MVC? Yes. Just as you can have the same problems with VIPER or MVVM.
The architectural pattern adapts to your app. Not the other way around. These patterns work as "suggestions" to your architecture — not recipes where you use the same ingredients following the same steps to obtain the same results.
Your app will need more than three or five letters if you wish to maintain a healthy, maintainable and organized architecture.
Patterns are a help, a guide, a direction. They're not the solution. They're not a religion. They allow, for example, a faster onboarding for a new team member, because the person might have previous experience with that architectural pattern.
But they don't guarantee tests, clean code, good development practices and none of them will save you from having recurrent bugs or a non-resilient software. Good developers and good practices will.
Which takes us to the next topic.
It is called PACTS:
An acronym of PAttern, Clean code, Tests/TDD and SOLID principles.
It consists of:
If you, and your team, apply the last three topics (the "CTS" part), the chances of good code, with a maintainable architecture and easy to evolve are bigger — regardless of the adopted pattern.
And, about the pattern, which one would be the best? Only your business, team and context can answer that question. VIPER may be overkill to a simple app with a team of two or three developers. But it can bring benefits in a large application with teams of ten or more developers.
Perhaps MVC will fit like a glove for you. That's right, MVC.
Or, maybe, none of these patterns will solve your problem. In this case, you can create your own. It can be even a mix of what already exists: nothing prevents you from using view models in conjunction with VIPER, for example.
Design, test, refactor and restart the process.
Who knows if your next architecture will hit the hall of fame? In this case, just remember that you're not creating a football team: it’s only a pattern that shouldn’t be followed slavishly.
We need good developers, good code, and well-written tests. It's time to do this pact.
Following MVC’s arrival, the community moved forward quickly. MVP (Model-View-Presenter) appeared, trying to fix the "everything is inside of my controller" problem with MVC. At the same time, MVVM (Model-View-ViewModel) added the View Model to represent your View and its state.
This alphabet soup of new ideas and architectures then exploded: VIPER, MVC, MVI, VIP, ReSwift, just to name a few. Each proposing different ways to architect your app.
At the same time, the discussions in the mobile community became more vociferous: Is MVC wrong? Does MVVM lead to huge and unmaintainable ViewModels? Is VIPER a complex and overkill solution? Which is the best choice?
None of these discussions are invalid, but people tend to forget some crucial points:
- All of these acronyms are architectural patterns. Your app is not in MVP or VIPER; your app uses MVP or VIPER — this is a really important difference that we'll explore later in the article.
- Your architecture design can follow any one of these patterns and still have an untestable, unreadable and confusing code.
We need more than an alphabet soup
There’s a long-running joke that neatly encapsulates some of the problems with MVC:"Model-View-Controller should mean massive view controller." And when it comes to view controller or activity, massive is a problem: it’s messy, complicated, unreadable and untestable.
But is all of this just down to MVC? I don't think so.
If you access your database directly from your activity, this is not MVC's fault. Are you making network calls from your view controller? That’s not MVC's fault either. Do you have to manage states in your fragment? Guess what? MVC is not the one to blame.
MVC means that your codebase will be structured around models, views, and controllers. It doesn't mean that everything must fit in one of these three boxes.
Let's take VIPER as another example. In this case, the acronym tells us that we should have a View, Interactor, Presenter, Entity, and (phew!) Router. But you probably will also need a database access layer, a network layer, GPS, disk persistence and so on.
Just like MVC, Viper is an architectural pattern that suggests entities around which you should architect your app. Again: it doesn't mean that you should fit everything inside of the proposed letters. You're free. Create as many layers as you need to keep your design consistent.
Can you have catastrophic results with MVC? Yes. Just as you can have the same problems with VIPER or MVVM.
The architectural pattern adapts to your app. Not the other way around. These patterns work as "suggestions" to your architecture — not recipes where you use the same ingredients following the same steps to obtain the same results.
Your app will need more than three or five letters if you wish to maintain a healthy, maintainable and organized architecture.
Taking benefit from the patterns
The biggest benefit of the patterns is that they propose a communality. MVVM, MVP, and all of the others were obtained through continuous reuse, observation, and refining, resulting in an abstraction.Patterns are a help, a guide, a direction. They're not the solution. They're not a religion. They allow, for example, a faster onboarding for a new team member, because the person might have previous experience with that architectural pattern.
But they don't guarantee tests, clean code, good development practices and none of them will save you from having recurrent bugs or a non-resilient software. Good developers and good practices will.
Which takes us to the next topic.
A new way of thinking
I would like to propose a new pattern for mobile projects. More than that: pillars in which the developers of your team need to agree. Pillars to guide. A new mindset. A pact.It is called PACTS:
Figure 1: PACT describes everything you need to build mobile apps
An acronym of PAttern, Clean code, Tests/TDD and SOLID principles.
It consists of:
- Pattern: MVC, MVP, MVVM, VIPER or any other. Don't follow it blindly: fit the pattern in your design, not the otherwise.
- Clean code: Writing code that works is easy. Writing elegant, focused, simple code that is made for humans to understand, not so much. Write a code that you will understand in the future.
- TDD & Tests: if your code is clean and organized but doesn't have tests you will invariably suffer from lack of resilience, multiple bugs and a long MTTR (mean time to repair). A well-tested code is good.
- SOLID: your architecture needs to be understandable, flexible and maintainable. A clean and tested code that cannot be evolved will cause you problems.
If you, and your team, apply the last three topics (the "CTS" part), the chances of good code, with a maintainable architecture and easy to evolve are bigger — regardless of the adopted pattern.
And, about the pattern, which one would be the best? Only your business, team and context can answer that question. VIPER may be overkill to a simple app with a team of two or three developers. But it can bring benefits in a large application with teams of ten or more developers.
Perhaps MVC will fit like a glove for you. That's right, MVC.
Or, maybe, none of these patterns will solve your problem. In this case, you can create your own. It can be even a mix of what already exists: nothing prevents you from using view models in conjunction with VIPER, for example.
Design, test, refactor and restart the process.
Who knows if your next architecture will hit the hall of fame? In this case, just remember that you're not creating a football team: it’s only a pattern that shouldn’t be followed slavishly.
We need good developers, good code, and well-written tests. It's time to do this pact.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
