To be honest, the real pattern is MVW (Model View Whatever).
The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events.
The big deal with all this is that we have a view, usually provided by a UI framework, a model, usually provided by the app developer, and some kind of loose coupling. That's it, the good old idea of separating data from its representation.
What you stick between the model and the view is just an implementation detail of your particular framework, optimized for your particular use case.
> The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events.
Well the article introduces weird new lingo which I don't think is all that great, but whatever.
"operations+events" can be equaled to "business logic". Let's keep that separated from the controllers. I want to create a new user via an http request, but I also want to do the same via a console command and since I want to do both things with the same code but one of these shouldn't be returning http status codes, it makes sense this should live in a different layer.
The whole events & operations separation in the article don't make sense to me. A "login attempt" as described in the article with a "login attempt" event being triggered by the view and that being picked by a decoupled "operation"? I don't see the value. If the operation needs to check privileges does it trigger an "check privileges" event, wait for another operation to complete? does that operation trigger another event to report the result? Wait a second... this sounds a lot like a convoluted Redux clone. Then you realize the only reason we are not doing Redux in the backend is because we are used to mutable state databases.
> To be honest, the real pattern is MVW (Model View Whatever).
It's not a pattern if it's not clearly identifiable as a pattern, MVC (original) applied to GUI interfaces. ASP.net tried to apply MVC to the web and it resulted in Webforms, which is true MVC, ASP.net MVC ironically isn't true MVC.
Like everything in IT MVC eventually became a buzzword thus lost all significance, that's why it doesn't really mean anything anymore since it doesn't describe anything specifically to most people who use the expression.
The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events.
The big deal with all this is that we have a view, usually provided by a UI framework, a model, usually provided by the app developer, and some kind of loose coupling. That's it, the good old idea of separating data from its representation.
What you stick between the model and the view is just an implementation detail of your particular framework, optimized for your particular use case.