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.
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.
> 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.
> 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.
This is exactly what I did with all projects I've worked on. It helped that I had to target both, iOS and macOS where sharing "business logic" was crucial, so you were kinda "forced" to think about that.
To put it simply, there is one question I'm asking myself, can I delete UI and then rewrite it from scratch without updating non UIView/NSView code (just calling MyClasses i.e. my APIs)? Let's just say, if I have to write NSSortDescriptor again, that means there is an architectural issue with my code, which has to be fixed.
Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API?
Please forgive the lack of background of this next question, but does this mean you do not support BFF pattern?
Have you heard of Dubray's SAM (State-Actor-Model) approach?
Curious about your replies and thank-you for your time.
> a low-level "engine" or "kernel" [..] and the view be any of a React Native mobile app, desktop app, or convenience web API
Yes, exactly that. Not my idea, of course. See for example Hexagonal Architecture. Or good old NeXT Enterprise Objects Framework, later extended by WebObjects.
> Have you heard of Dubray's SAM
No I hadn't, thanks for the tip!
He identifies one of the core problems with how MVC is incorrectly applied:
"The core issue here is [that in] traditional MVC, the action (controller) would call an update method on the model and upon success (or error) decide how to update the view. "
However, he incorrectly claims that this is "traditional MVC". It is not. In fact, traditional MVC clearly forbids this, as it states that the View updates itself from the model. The View is active, you don't push data to the view.
Model -> View communication is a notification. That's it. (This is also how it is implemented in Smalltalk MVC, which is the prototypical and archetypical MVC implementation).
Thank-you for your reply. I had another question about models and the database.
It feels to me that the database tends to be more stable over time than the application: frameworks, design approach, and architectures come and go, but tables, stored procs, and views have always been there.
That said, supposing we were to start with the data model and many business rules expressed in the database first, would you reach for GraphQL to help the app manage the data it needs, or acquiesce custom db objects to provide the required data?
With SAM, I thought there would be a way to avoid BFF, while conforming to a TLA+-ish way of enforcing (the model's valid) states at all times.
I know I am handwaving a lot of ideas. Just wanted to get your input on the backend side of things.
> Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API?
Let me present: Kotlin Multiplatform Mobile[0] (or KMM, a real mouthful I'll grant you). Something I'm very excited about, because you could do exactly that. Seems like an interesting thing to keep an eye on.
Sounds neat, thank-you. Have you heard of Java Cuba/Jmix?
From my limited, surface understanding, that is what KMM reminds me of: a way to define UI in Java, which means the entire stack could be in a single language (or mix of JVM languages).
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.