UIKonf18 - Day 1 - Joachim Kurz - MVC is Not Your Problem

MVC is Not Your Problem
In recent years, more and more criticism of 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. In this talk, we will see that most criticisms of MVC do not really understand what MVC does and does not prescribe. But more importantly, they miss the point: The architecture pattern is not the problem, how we use it is. We will see that other architectures are prone to the same problems as MVC and we will see how to address them in both MVC and other architectures.

[@alexitosworld]

One of the best architecture talks I’ve seen!

[@isurujn]

I'm about 4 years late to see this talk but still holds true. Fantastic presentation. Learned not only about hidden areas of MVC but other tidbits too. Like the cost of premature reusability-centric design and where to place the programmatic UI code. I wish the talk had some code samples regarding the different types of controllers though.

[@zark4711]

Nice focus on clear ideas instead of dogmatically following architectural patterns. MVP, MVVM, VIPER have not helped me a lot. They made later changes/refactorings in the app a pain. They bloated a 100 line MVC into an 80 line View(Controller) with another 80 lines presenter. What for? Should we have a Network Layer, Service Layers, Data Repositorys, Models and even View related Models? Yes, I agree. But moving data through additional layers like VIPER, that all just do tiny bits, scattering the logic, does not help for understanding and reasoning. Reading code just becomes following spaghetti calls into nirvana. And if you want to put something on top, you can use protocols for everything (that is never going to get another implementation, than the one provided) and put them into separate files. I know, that this is useful for testing and mocking, but during development it is jet another file of indirection to open and to look at. Can't we do things functionally (side effect free). Can't we do things locally? Can't the state of the view just declared as a function of the view model? I think so! Thanks for this great talk! You are mostly speaking from my heart and for the rest: they were good ideas, I was not aware about. (And for Interface Builder: yes please, as much as possible! As a side note: I was surprised lately by some ReSwift code, that came with no interface files, yet was very readable and did not feel cluttered with UI related code.)

[@sustainableCode]

I’m wondering where he takes these random numbers on reusability..

[@sboboski111]

Terrific explanation thanks Joachim, is your talk from IOSDEVUK in September talk available anywhere?

[@mostafaelshazly6734]

This is an awesome explanation! thank you so much for it

[@royhsu510]

Really excellent talk!

[@wassmd84]

MVVM pattern rocks! be it is Testing, solid principles, single responsibility... MVVM is one stop go ;)