4 ms·

Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM

by mojuba 4y ago

Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.

mpweiher 4y ago
MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
- marcosdumay 4y ago
  It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours. The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
- jim180 4y ago
  Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(
  - mpweiher 4y ago
    What's important to realise is that the elements in MVC are roles not entities. So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role. Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...
    - jim180 4y ago
      agree again. offtopic: love your blog!
andix 4y ago
Exactly, those patterns may be good if you know exactly what you're doing. But in all the other cases, they just make everything more complicated and harder to understand. I've once worked with a messy codebase, it was written in a very "naive" way, but that was also the strength of that code. Every view was in one file, every action was just one method, so you exactly knew what code was executed when. We tried to refactor it, but it became complicated really quickly (the domain was really complex), so we decided to just adopt to the style. We only split up components that became to big into smaller components, sometimes decoupled things a bit, but most of the time just kept all the logic. And this product is successfully in use for over a decade now.
- mojuba 4y ago
  I find that in larger GUI apps the best thing to have is a layered architecture where visual and non-visual parts are separated globally, not on a view-by-view basis. One advantage of this is that you can slice off your visual part and have something like a "headless browser" variant of your app. Among other things this is good for writing integration tests if you also have a backend. Same trick is impossible or very difficult to do with MVVM.
  - mpweiher 4y ago
    > visual and non-visual parts are separated globally, not on a view-by-view basis Yes, yes, and YES! This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell. I would implement my model, TDD-style, put minimal views on top, possible add a view-model here and there if there was some display-specific logic that was complex enough to warrant more extensive testing, voilà. It was only recently, partly when working with some teams that were doing modularity for modularity's sake (and MVVM for MVVM's sake), and partly when writing down Blackbird[1] that I really noticed the per-view thing. Don't do that. >"headless browser" variant of your app Exactly. Do this. The app is an object. It has an API. It knows how to coordinate its pieces. The local I/O, the remote I/O, any timing stuff. All of it. Then you plonk the UI on top of that. You can have sub-parts, but you need one piece that ties it all together, on the model side. > Same trick is impossible or very difficult to do with MVVM. Well, it's impossible with the misapplication of MVVM that is common today. A view model is a perfectly fine addition if you have some complex but fairly presentation-specific logic. And you put that in a testable model that is fairly tied to one view. Instead, people have used MVVM to double down on their view-centric misunderstanding of MVC, with anemic models that know just enough to service a specific view. Meaning any kind of cross-app logic can't go in the model. Meaning it is going to go into the view parts (or rather: the misnamed and misapplied controllers). Which is exactly where it has absolutely no business whatsoever being. Sigh. [1] https://blog.metaobject.com/2022/06/blackbird-simple-reference-architecture.html https://blog.metaobject.com/2022/06/blackbird-simple-referen...
wellanyway 4y ago
Out of curiosity, what's fashionable these days? As opposed to MVC?

by mojuba 4y ago

mpweiher 4y ago

MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).

marcosdumay 4y ago
It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours. The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
jim180 4y ago
Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(
- mpweiher 4y ago
  What's important to realise is that the elements in MVC are roles not entities. So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role. Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...
  - jim180 4y ago
    agree again. offtopic: love your blog!

andix 4y ago

Exactly, those patterns may be good if you know exactly what you're doing. But in all the other cases, they just make everything more complicated and harder to understand. I've once worked with a messy codebase, it was written in a very "naive" way, but that was also the strength of that code. Every view was in one file, every action was just one method, so you exactly knew what code was executed when. We tried to refactor it, but it became complicated really quickly (the domain was really complex), so we decided to just adopt to the style. We only split up components that became to big into smaller components, sometimes decoupled things a bit, but most of the time just kept all the logic. And this product is successfully in use for over a decade now.

mojuba 4y ago
I find that in larger GUI apps the best thing to have is a layered architecture where visual and non-visual parts are separated globally, not on a view-by-view basis. One advantage of this is that you can slice off your visual part and have something like a "headless browser" variant of your app. Among other things this is good for writing integration tests if you also have a backend. Same trick is impossible or very difficult to do with MVVM.
- mpweiher 4y ago
  > visual and non-visual parts are separated globally, not on a view-by-view basis Yes, yes, and YES! This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell. I would implement my model, TDD-style, put minimal views on top, possible add a view-model here and there if there was some display-specific logic that was complex enough to warrant more extensive testing, voilà. It was only recently, partly when working with some teams that were doing modularity for modularity's sake (and MVVM for MVVM's sake), and partly when writing down Blackbird[1] that I really noticed the per-view thing. Don't do that. >"headless browser" variant of your app Exactly. Do this. The app is an object. It has an API. It knows how to coordinate its pieces. The local I/O, the remote I/O, any timing stuff. All of it. Then you plonk the UI on top of that. You can have sub-parts, but you need one piece that ties it all together, on the model side. > Same trick is impossible or very difficult to do with MVVM. Well, it's impossible with the misapplication of MVVM that is common today. A view model is a perfectly fine addition if you have some complex but fairly presentation-specific logic. And you put that in a testable model that is fairly tied to one view. Instead, people have used MVVM to double down on their view-centric misunderstanding of MVC, with anemic models that know just enough to service a specific view. Meaning any kind of cross-app logic can't go in the model. Meaning it is going to go into the view parts (or rather: the misnamed and misapplied controllers). Which is exactly where it has absolutely no business whatsoever being. Sigh. [1] https://blog.metaobject.com/2022/06/blackbird-simple-reference-architecture.html https://blog.metaobject.com/2022/06/blackbird-simple-referen...

wellanyway 4y ago

Out of curiosity, what's fashionable these days? As opposed to MVC?