3 ms·
that doesn't change the fact that you have a model in which 2 of the 3 roles just fuck around doing nothing, and 1 is doing everything (and has more classes). I
by nsonha 5y ago
that doesn't change the fact that you have a model in which 2 of the 3 roles just fuck around doing nothing, and 1 is doing everything (and has more classes). If you ask youself the question: "what does this logic belong to?" and most of the time it's the same good damn role, then are the roles useful as guideline?
- gurkendoktor 5y agoI wrote "when you are in a situation..." - but that's not generally my experience, instead controllers are often cluttered with rendering details like colors and animations, networking code, or things that I would've put in the model layer. To give some context, I remember reading an article about massive view controllers and one example was Firefox for iOS, so I've dug up a snapshot of its main view controller, which exhibits all the things people hate about Apple's MVC: https://github.com/mozilla-mobile/firefox-ios/blob/21e9d294343fb43af967c73cb142603d4dc59b57/Client/Frontend/Browser/BrowserViewController.swift https://github.com/mozilla-mobile/firefox-ios/blob/21e9d2943... I have met Swift teams who would have proudly refactored this outdated MVC code into a "modern" MVVM pattern, replacing the 2000 LOC controller with one 2000 LOC ViewModel and a 500 LOC controller (because you still need UIViewControllers in the Apple world). But in my opinion the bigger issue is the insistence of only having one controller, or view model, or whatever per screen. As soon as you find a way to divide all the interconnected concerns of this screen, the layers and their names are not really that interesting.