MVC Isn’t MVC

• Model is “whatever you need to store persistently, how you represent that data, how should the data be structured and stored when it’s at rest (eg in a database, nosql environment, or big data query system), how you are expected to query that data when you need it, mediates common CRUD data query operations on the store, and broadly handles giving back the results of any stored data query. Intent of the model is to be a black box the controller can talk to whenever it needs something from “storage”. If you did it right, you can change the entire underlying data store and endpoint, and as long as the API for the model is preserved, the controllers don’t even notice.

• Controllers mediate “turning prepared or cached model data queries into something to give back to the user” and “listening for the user wanting to do something and responding appropriately by fetching needed model data or server resources”. Handles moving between pages, incoming API calls, last mile data filtration (where last mile is based on milliseconds to do it, >25ish or so and it probably belongs on the model) and cleanup if any is needed, and is first line of contact (and defense) for anything a user’s triggered.

• Views are whatever the user can visibly interact with and see, and provide buttons, links and interactibles which hook into controller calls to change things or give back data

I’ve found the above model typically has good separation of concerns, usually avoids most fights of “does this belong on the model or controller”, and you can usually cleanly parallelize work between multiple people on a small team if you use ~~waterfall~~ scrum to agree on a data model for each endpoint and needed functions before starting.

Original WebObjects tried to ignore the web's statelessness by keeping state on the server, and encoding state in a path param in every URL. It was not exactly designed to fit a stateless environment as designed to let the developer ignore the fact that the environment was stateless, put an abstraction on top that made it appear stateful. But maybe that's semantics. But later WebObjects, towards the end of when it stopped being a commercial product, grew out of this -- it was in fact a very bad fit for the web. Encoding an opaque identifier in every URL to connect to back-end state is bad for cache-ability, idempotency, persistent URLs, etc., it's not what Tim BL or Roy Fielding wanted from URLs at all.

BUT, despite all that (differences in "routing", URL-to-app mapping), as far as the MVC break-down, the original WebObjects was still very much like the architecture of Rails, to the extent that I've often wondered if the Rails originator(s) were exposed to WebObjects.

But, then, I'm not sure that this architecture, actually was motivated by, as OP says: "but in a way that makes sense for the web. The components don't have references to each other, because and nothing is alive. Each object is only around long enough for the page to be rendered" -- because the earlier WebObjects, as far as MVC split very much like Rails, in fact did it's best to keep the objects alive after all on the back-end, and provide abstractions that hid the statelessness of the web from the developer, connecting each HTTP request to the kept-alive-in-back-end objects, where things did have references to each other, or appeared to, that ought to have not been possible. But still had the same MVC breakdown that could be diagrammed the same way.

Actually here's a 2001 version of the WebObjects manual, note they are pointing this out as different than classic MVC, but it is very much like Rails too.

> Note: WebObjects uses the term “model” differently from MVC. In WebObjects, a model establishes and maintains a correspondence between an enterprise object class and data stored in a relational database. In MVC, model objects represent the special knowledge of the application.

— https://developer.apple.com/library/archive/documentation/Le... page 28

More on MVC in WebObjects there too

> Acting as a mediator between Model objects and View objects in an application is a Controller object… Because of the Controller's central mediating role, Model objects need not know about the state and events of the user interface, and View objects need not know about the programmatic interfaces of the Model objects.

Familiar, right? And different from what the OP is saying was original MVC; maybe consistent with both what OP calls Apple-style as well as Rails-style MVC?

I haven't found an earlier dated WebObjects manual online (such as actually from NeXT days!), but they definitely existed, would be interesting to see how they referred to MVC.

You can see a little bit about the weird ways original WebObject tried to encode state in URLs, mapping to persistent back-end state, in this other legacy WebObjects doc I found on the web, see "Component Action URLs" on page 12, and following through page 17. https://wiki.wocommunity.org/download/attachments/1049043/We...