> apple’s models had to be « dumb data containers ».
They don't "have" to be, but that's very much the result of what Apple has been advocating, what the community tells itself and what happens.
> Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in.
Exactly. And the coordination logic. Alas, that is exactly what happens, and I've been in enough of these codebases.
It's actually a bit more complex than that, as what people seem to aspire to is write self-contained widgets for their functionality, essentially slicing the application vertically most of the time. And that appears to have a bunch of causes, for example the PM->Design->Engineering process chain that also appears to be standard (and broken).
> My take on the model layer is : write everything that’s not strictly specific to your UI there.
YES.
UNDERLINE.
BOLD.
BLINK.
Repeat 100 times. Say it loud. Sing it. Shout it.
The "Model" is an object that is the headless application. It implements and coordinates all the functionality. You put a thin GUI on top of that. Or a different GUI. Or an API. Or a WebUI. Or a CLI....
> The "Model" is an object that is the headless application
Wow, that's a great mental model (wink) to have.
I never thought of it in those terms, but I think I do follow it, mainly because I tend to follow John Ousterhout's guideline of "Deep Modules, Small Interfaces".
This way the model ends up being exactly what you're talking about. It is testable, issues are easier to reproduce, it's easier to reason about, it is portable to other contexts: server-rendered web app, JSON API, GraphQL API, desktop app, mobile.
I think the biggest obstacle for people using popular frameworks is realizing that a "Model" doesn't have to be necessarily one single class. The important part is having a model-like API that is good and self-contained. Previously I didn't have a mental model for what is "good" but with your comment I think I can put that into words a little better.
One of the biggest problems I have with Services and other patterns such as Operations, Interactors is that developers often couple them to Controllers and Views. Also often I see duplication happening when new patterns are added because they're seen as separate. If you think of them as "part of the model", however, and follow the "the model layer is its own headless application" those issues have a smaller chance of happening.
that's also my tip for devs working in my team when they ask me where they should write a piece of logic :
- would you need to change that code if the UI is now a command line application ? No ? then it's in the model layer.
EDIT: i've also been in those codebase a LOT, and actually decided to create a blueprint of a mobile codebase with an emphasis on the model layer. I'm not going to post it here because i want to remain anonymous, but i've been using it in my projects (and my friend's have been doing the same) for the past 6 years..
I usually never ever advise my customers to rewrite their app from scratch. And yet here i was, doing it for the 4th time in a row for 4 different customers, in just 2 years, simply because the codebase were a total mess each time.
So i thought "well, there's got to be a problem with iOS developers here in Paris". And so i decided to give a talk to the largest iOS dev group in Paris to show my model layer template.
I started with a poll : who has ever heard about "layered architectures" ?
Well, there was about 100 people in the room, and only 2 people raised their hands. I talked to them afterwards, they were both backend developers originally, and were absolutely stunned nobody else in the room knew the term.
So, that was just to tell you that the problem is a cultural one. Apple never ever mentions architecture in their documents / talks. So most mobile devs that start in this path start by coding fancy animations, and only much MUCH later, after a lot of projects turned ugly, do they start to realize there is another world for them to discover.
They don't "have" to be, but that's very much the result of what Apple has been advocating, what the community tells itself and what happens.
> Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in.
Exactly. And the coordination logic. Alas, that is exactly what happens, and I've been in enough of these codebases.
It's actually a bit more complex than that, as what people seem to aspire to is write self-contained widgets for their functionality, essentially slicing the application vertically most of the time. And that appears to have a bunch of causes, for example the PM->Design->Engineering process chain that also appears to be standard (and broken).
> My take on the model layer is : write everything that’s not strictly specific to your UI there.
YES.
UNDERLINE.
BOLD.
BLINK.
Repeat 100 times. Say it loud. Sing it. Shout it.
The "Model" is an object that is the headless application. It implements and coordinates all the functionality. You put a thin GUI on top of that. Or a different GUI. Or an API. Or a WebUI. Or a CLI....