Hacker News Reader

> You take a table from the database and put it into an html tag table.

> Do you want your view to know how to connect to a db?

I think this is where there's a misunderstanding: you think of your model as "a database". A database is not a model, a database is just a storage layer. A model is an object that provides an api with high-level business operations and views on data.

At that point, your view needs only to receive from the model the pre-digested data it provides and translate it into html. Similarly, the controller only needs to translate user input in terms of high-level operations on the model, without ever having to interface with a database.

In fact the original MVC was done with Smalltalk which has a persistent image. So the Smalltalk system itself _is_ the storage layer in which model objects live.

This!

Also the original MVC (not the req-resp cycle Model2) was not for client-server split apps. It was for desktop apps, so the Model could update the view. Now with WebSockets we're coming full circle.

Exactly! No rows, tables or SQL. But instances of Models in a persistent image.

> A model is a ... view on data.

I think this is part of the reason the MVC names persist, they are so generic that you can describe the Model as a type of View!

MVC “view” is on the user level, the model is a “view” (facade/adapter/whatever) on the programmatic level.

The way I typically think of it is

• 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.

I more or less agree, the main issue with your "Model" is that it doesn't separate Data from Service (or Manager or Database or whatever your data-management layer looks like).

A lot of "MVC" has Model as a dumb Data-Model, and data is passed around between the service/manager/db and controller a lot. It's very rare (that I've seen) that you truly have so-called Model code talking directly to the controllers.

There is also the question of data-flow in larger "MVC" containers - where either numerous "views" must co-operate (e.g. in the case of complex nested lists), and must choose some combination of view-to-view communication (often in the case of layout-intense code), or view-to-controller-to-controller-to-view communication, or in some cases view-to-controller-to-service-model-to-controller-to-view communication.

Often the pattern applied to de-congest such a system is a service-oriented or micoservice, or event pattern, although all of these tend to introduce overhead and hence in-efficiencies compared to tightly coupled e.g. view-to-view communication, or tightly coupled controller to controller communication.

I suppose what I am arguing is that Model is a bit of a misnomer - you must always operate upon data, all code is simply transforming that data and the best way to transform that data is usually context specific to some combination of business and practicality needs... so the "Model" unless strictly defined as "the raw data structures" tends to somewhat overlap and envelope the other roles.

> You take a table from the database and put it into an html tag table. Wait, who is “you”? The model?

The model tells the view about itself. This is early O O. Everything is an object. And objects have power and self awareness. When the view receives the message telling it about the model, it does what it has to do to make the model viewable.

So the model and the controller don’t know about html. The view received a message (the current state of the model, or a delta thereof) and responds accordingly.

The model is the storage abstraction -- it knows how to load and save itself to the database.

The view is the output abstraction -- it knows how to generate the HTML from the model. It doesn't know how to load and save to the database.

The controller is what puts these things together. It interacts with the model to get it loaded and passes it to the correct view for display.

MVC is a frontend paradigm

When you're talking about a table of Users you are talking about an entity of User. This can contain extra stuff that's not relevant to the frontend - like the password or lastUpdatedDate, you name it.

In your example, when you talk about a Model, you talk about a user Entity representation. There's a transformation there. The frontend posts a Model (or a DTO) to the backend API, the backend does the transformations it needs (e.g. retrieving the user Entity based on the model user id, mapping updated field values from the model to the Entity, and saving the Entity to the database).

The view is the representation template, the model is what's needed to fill in the template, and the controller does CRUD operations to a backend API.

Edit: or is this MVVM? These days I mainly do backend stuff but I used to call this MVC

In Apple MVC, the view controller is IMHO actually primarily a way of avoiding the need to subclass views. After about 25 years with one or the other form of MVC, I am convinced that most of it is just born out of a weird OOP mental model.

There is a 5000 line controller in one code base I worked on that speaks directly to this. I argued for something more modular/structured like MVVM because every bit of code where these questions arose would just end up in the controller in a grab bag of helper functions, which is exactly what happened.

I don’t think MVVM solves 5k line in a controller issue. You can write monster code using any style, language or pattern.

Nothing can stop bad code but MVVM helps as it is a better mental scaffold than the "everyobne 'knows' what it is but no one can agree what it is" MVC

Hexagonal architecture is great when you learn to separate domain logic from application logic.

Domain logic can be in your entity classes or in separate service classes next to them, but it's still the model.

The controller then deals with application logic: get the data, apply domain logic, save the data, send out notifications, pass the update to the view.

Indeed. Th C in MVC must stand for carcinization, given how often completely independent parties reinvent this one.