MVC is Not Your Problem
updated about 1 year ago; latest suggestion about 1 year ago
In recent years, more and more criticism on the Model-View-Controller pattern (MVC) surfaced and MVC was often blamed for causing too much code in one place and too closely coupled code ("Massive View Controller"). Lots of different patterns were proposed to solve the "MVC-Problem" from MVVM over MVP to VIPER and more.
But they all miss three important points:
- MVC (neither in general nor in Apple's variant) does not require us to put everything in the View Controller. In fact, if applied appropriately, most of the functionality won't end up in the View Controller.
- In my experience, the proposed patterns often do not solve the actual problems. They introduce more layers for functionality and split the functionality into horizontal layers between roles/responsibilities, which often just leads to a still massive ViewModel/Presenter/Interactor. Instead, splitting into vertical "columns" by functionality would be much more useful.
- They do not mix well with the existing UIKit architecture. You always need adapters or weird workarounds to force UIKit to your will. Or you even start to implement your own ViewController-like base-class and call it a presenter. You spend much too much time just forwarding stuff until it reaches a destination.
In this talk, I will briefly show that MVC, as blamed for "Massive View Controller", is grossly misunderstood and then give recommendations how to split your app into manageable parts, while staying with MVC and extend it where necessary. Instead of applying the single responsibility principle only on the technical level (splitting into views, controllers, models, interactors, presenters), I will encourage you to focus it much more on the domain level, split your models into separate separate sub-models, your controllers into different sub-controllers, and so on. Focus on composability, not layering. Doing this allows us to get away with a much simpler architecture on the technical level and cures us from the believe that there can be the one perfect app architecture. Every domain we build our app for is different and thus, every architecture must be different.
I have worked on a more than 5-year-old iOS app with more than 300.000 LOC for the last two years. Within this app, I can see different programming fashions live side-by-side depending on the year the code was written in. While working on this app, I learned that it doesn't matter how many layers you introduce, if you don't know how to split functionality into composable parts. And if you do, you can get away with much fewer layers.
Thanks for being willing to stand up for MVC. Most of the times folks complain about MVC, I have to wonder whether they truly understand how to implement it or whether they're just following some (admittedly) bad examples.
One of the questions I frequently ask folks complaining about Massive View Controllers is "Who told you your data source had to be implemented in your VC? Sure Xcode does that by default, but no one's making you do that."
I'm eager to see your take on this.
Thanks for asking. The app itself is much older, but the last rewrite is about 5 years ago. So in the meantime it was never completely rewritten.
Accordingly, it’s still mostly Objective-C, but we usually write new features on Swift. But the majority is still Objective-C.
How many times your 5-years-old iOS app was rewritten from the scratch? Is it still on Obj-C partially? Just wondering, because having similar oldie project, which was written using MVC. After programming on Swift using MVVM+C architecture, looking at this project making me just said.