3 ms·

It's very similar you're correct, particularly when you add in the Manager/Service layer (something that I hadn't spent enough time investigating). The main ad

by cirwin 14y ago

It's very similar you're correct, particularly when you add in the Manager/Service layer (something that I hadn't spent enough time investigating). The main advantage of Operations over controllers is that they're fully composable. You can take the operation that logs a user in (which displays the login screen, and awaits the user typing a username and password) and use it as a sub-part of any other operation. In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. I'll certainly be following up with more details, and some actual code.

scrame 14y ago
Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should be happening in the area of the business logic. I understand the motivation, and have come across several situations where I wanted "controllers calling controllers", but ultimately, you're repurposing a piece of the architecture to do something it shouldn't be doing. A controller handles the input into the system, it shouldn't be defining a workflow. > In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. That just sounds backwards to me. Are talking about creating dynamic endpoints? That sounds like a much bigger headache than composing stuff in a service layer. MVC can be a little ambiguous, and with web-frameworks it can be hard to see that each piece is actually a subsystem. The Model isn't just your model class, its the model class, the DB and the ORM library you are running. Similarly, the View is the entire response / template rendering subsystem. The part that is addressed in the framework is mostly the "controller" subsystem, which is a way of organizing code so that the actual "controllers" can do the primary work of sanitizing input, delegating function calls and returning the output to the View system. Again, MVC is just a pattern that doesn't fit perfectly in the web request/response cycle, which then necessitates a pattern to handle the leakage (in my case I'm talking about the service/manager pattern). However, I just don't see your suggestions that MVC is "dead", or how this system is radically different. It seems like it is just semantics.
eaurouge 14y ago
This thing you're calling MOVE, how is it different from Qt's MVC + signals and slots [1]? You've discovered a new (for you) way of applying MVC and you've gone ahead and given it a new name. Nothing in your blog post is new, except the name of course. If I sound snarky, it's because I'm sick and tired of similar opinionated proclamations in too many self-important blog posts. Edit: Re the down votes. If you're going to write posts with titles like "MVC is dead" with no justification whatsoever, then proceed to self-post on HackerNews, then I feel justified calling you out on it. Again, I would appreciate someone informing on how MOVE is fundamentally different from MVC. 1. http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html http://doc.qt.nokia.com/4.7-snapshot/model-view-programming....
einhverfr 14y ago
So I am trying to understand the difference. Suppose I have an MVC web app. Suppose I add some database triggers so that when some data is entered other things happen. Maybe I flag an invoice to be printed and the trigger notifies a waiting program which processes the invoice data and sends it to the printer. Now, from the perspective of any single request, the application is MVC-centric. However, from the perspective of the application structure as a whole it's not, because model operations trigger other operations which can have other effects beyond the immediate knowledge of the model. Is that kind of what you are talking about? MVC with a sort of events backplane?
demallien 14y ago
The controller in MVC does have a bit of a dual nature, firstly it acts as glue code between models and views, allowing the two to be effectively de-coupled. The second task is a little more complex - views take user input eg mouse-clicks and key presses, and translates it into semantic events "OK button clicked", "Open File selected", which are then acted on by the controller. Your post explicitly identifies these two roles and formally seperates them. This is perhaps not a bad thing, but I don't know that it justifies the title. Something like "The two faces of an MVC controller" might have been a better description...

by cirwin 14y ago

scrame 14y ago

Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should be happening in the area of the business logic. I understand the motivation, and have come across several situations where I wanted "controllers calling controllers", but ultimately, you're repurposing a piece of the architecture to do something it shouldn't be doing. A controller handles the input into the system, it shouldn't be defining a workflow. > In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. That just sounds backwards to me. Are talking about creating dynamic endpoints? That sounds like a much bigger headache than composing stuff in a service layer. MVC can be a little ambiguous, and with web-frameworks it can be hard to see that each piece is actually a subsystem. The Model isn't just your model class, its the model class, the DB and the ORM library you are running. Similarly, the View is the entire response / template rendering subsystem. The part that is addressed in the framework is mostly the "controller" subsystem, which is a way of organizing code so that the actual "controllers" can do the primary work of sanitizing input, delegating function calls and returning the output to the View system. Again, MVC is just a pattern that doesn't fit perfectly in the web request/response cycle, which then necessitates a pattern to handle the leakage (in my case I'm talking about the service/manager pattern). However, I just don't see your suggestions that MVC is "dead", or how this system is radically different. It seems like it is just semantics.

eaurouge 14y ago

This thing you're calling MOVE, how is it different from Qt's MVC + signals and slots [1]? You've discovered a new (for you) way of applying MVC and you've gone ahead and given it a new name. Nothing in your blog post is new, except the name of course. If I sound snarky, it's because I'm sick and tired of similar opinionated proclamations in too many self-important blog posts. Edit: Re the down votes. If you're going to write posts with titles like "MVC is dead" with no justification whatsoever, then proceed to self-post on HackerNews, then I feel justified calling you out on it. Again, I would appreciate someone informing on how MOVE is fundamentally different from MVC. 1. http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html http://doc.qt.nokia.com/4.7-snapshot/model-view-programming....

einhverfr 14y ago

So I am trying to understand the difference. Suppose I have an MVC web app. Suppose I add some database triggers so that when some data is entered other things happen. Maybe I flag an invoice to be printed and the trigger notifies a waiting program which processes the invoice data and sends it to the printer. Now, from the perspective of any single request, the application is MVC-centric. However, from the perspective of the application structure as a whole it's not, because model operations trigger other operations which can have other effects beyond the immediate knowledge of the model. Is that kind of what you are talking about? MVC with a sort of events backplane?

demallien 14y ago

The controller in MVC does have a bit of a dual nature, firstly it acts as glue code between models and views, allowing the two to be effectively de-coupled. The second task is a little more complex - views take user input eg mouse-clicks and key presses, and translates it into semantic events "OK button clicked", "Open File selected", which are then acted on by the controller. Your post explicitly identifies these two roles and formally seperates them. This is perhaps not a bad thing, but I don't know that it justifies the title. Something like "The two faces of an MVC controller" might have been a better description...