You can add other layers and frameworks in addition to using MVC. That doesn't mean MVC is pointless.
You can add other layers and frameworks in addition to using MVC. That doesn't mean MVC is pointless.
But the topic is MVC not some particular application. I think jerf's point is that it's weird to say that a service layer is an important part of working with MVC when it's not even part of the same idea. Your statement here confirms that.
One can be talking about an expansion of the idea of MVC as if it were MVC itself, but that just proves jerf's point, too, about MVC being meaningless.
It's quite possible, I would think, to define an entire application in terms of Models, Views, Operations and Events.
I'd have to try it for awhile to determine if it's a good idea. It's pretty compelling however. I may give this a spin next time it comes up.
And "Events" is essentially Controller code.
(There might be an argument that this describes a "fat" model vs some devs/frameworks choosing "thin" models that are just state rather than state + logic. )
Operations is pretty much a rebranded Controller, here. But it's a good rebranding! I've seen Controllers turn into a "God class" too many times, where you end up with big lumps that do more-or-less everything.
Or, what's closer to the original paradigm, you have one Controller per Model, but that's the thing: a given action will routinely involve two or more models. Do you put a bit of persistence logic in the User Controller or the Session Controller?
Thinking in terms of Operations should encourage small classes that each do one thing, and follow their own logic, not View logic or Model logic.
And having everything communicate through well-defined Events is great, this would make it much easier to add additional sources and sinks by reusing an already-established Event with a new Operation.
The more I think about it the more I like it.
A Model View Repository Controller Service framework!