That’s a fair critique. Though the snark was unnecessary.

I took the time to reread the literature and review my actual code. My updated understanding.

Model controls and holds the state of the system. It ensures the data is always valid.

Controller controls the boundary between the system and the user.

View represent the model and capture user intent to change the model. They ask the model for data they need; however I disagree with the practice that views change data directly but instead prefer they send an intention to change to the app which does the work.

Auth was not considered in 1979 as far as I can tell. Authentication is part of the “controller” but in middleware usually because it’s part of the user input boundary, and generally better if done in one place early in the event lifecycle. Authorization is part of the model.

App logic is decomposed into workflows or use cases in the app layer. Events coming in through the controller are translated into what the system understands and then passes it onto the workflow to execute.

Thus these should take change intent from the view and then actually tell/ask the model what needs to change. This allows the app to catch errors from the model, recover if they can, or handle multi step flows. Results and errors are then sent back to the view (eg GUI dialog) or controller (eg api call) that initiated the workflow.

This makes it easier to put different views over the same app logic (mobile, web, api, agent) and also test workflows in isolation.

Modern views have their own controllers for mouse and keyboard. That’s fine. Don’t care. That’s effectively outside the system in the client experience (eg browser) anyway.

Where I have trouble is when I

- put a ton of app logic in the controller

- put a ton of model updates in the view

- have a single controller for the entire system instead of one per system boundary/interface of user events.

The (DDD?) style of app logic being encapsulated outside of the controller makes a lot more sense to me now that I see it.

▲

mpweiher 3 days ago | parent [-]

Hmmm...the problems you recount are exactly the problems of putting (way too much) logic into the controller...and not enough logic into the model...which is exactly what MVC recommends you not do, and which is exactly what I criticized about your approach...and which is exactly the critique you seem unwilling to accept.

¯\_(ツ)_/¯

What gives?

Put all the logic in the model. If you want authentication, put that in an "authenticated model" that wraps your model. Don't put it in the controller.

> Controller controls the boundary between the system and the user.

Nope. That is Apple-MVC. Aka Massive-View-Controller. It is not MVC.

The model API is the boundary between the model and the rest of the system.

https://blog.metaobject.com/2015/04/model-widget-controller-...

▲

sunir 3 days ago | parent [-]

The controller is meant to be handling things like keyboard events or http events. That’s the boundary to the user. The thinner the better.

I don’t know why you think this is a combative conversation where I need will to accept or reject anything. I lack understanding of how you would solve the same problem. Throwing chaffe is not communication. It creates a second problem beyond the one we are discussing.

How does the model handle authentication without having to become aware of boundary protocols? How the user authenticates is part of the input to the system. Eg http basic or oauth

I don’t know how you handle routing. Do you put that in the model as well?

▲

mpweiher 3 days ago | parent [-]

> I don’t know why you think this is a combative conversation where I need will to accept or reject anything.

You replied to my post, contradicting me. ¯\_(ツ)_/¯

> The controller is meant to be handling things like keyboard events or http events. That’s the boundary to the user.

You keep repeating this, it keeps not being true in MVC.

> I lack understanding of how you would solve the same problem.

I described how I would solve the problem.

> How does the model handle authentication without having to become aware of boundary protocols?

It gets passed required information. Just like it gets passed other information.

> I don’t know how you handle routing.

I personally handle it by having in-process REST available in my language. So I don't have to translate from URIs to methods before I reach the model.

https://objective.st

You might have mentioned before that you are talking explicitly about web programming, where the concept drift from actual MVC to what is called MVC nowadays is even greater than in GUI programming.

MVC as described by Trygve is for GUI programming.

	▲	sunir 3 days ago \| parent [-]
		lol, contradictions about MVC are par for the course. It's not personal. It's just confusing. Talking about the concepts isn't the same as talking about each other as professionals. Some of the articles you linked to express this tumult over decades. Looking at 1979, when I read this. > A controller is the link between a user and the system. I think of it as the boundary > It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It's the router, or view loader. > It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on .to one or more of the views. The controller receives user input, translates it, and dispatches the input to the views. I think this has changed in the modern era. > A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them. I don't really understand this exactly, but I think it means views compose themselves. > Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands. The controller handles the raw input and translates it into actions/commands meaningful to the system. >> How does the model handle authentication without having to become aware of boundary protocols? > It gets passed required information. Just like it gets passed other information. Is what you consider the model all logic in the system? I would not. I would consider the model to be the data in the system world, using terms in systemese. It shouldn't know or care about OAuth or SAML or HTTP Authorization or whatever. It would care about Users and Sessions. However, is this semantics? The use case and work flow approach is just a layer on top of the data model. The auth is another layer. Why it matters to me is I prefer to think of systems as data flows, and the code follows the data flow. Control layers are different than the actual data.