3 ms·

MVC does not comprise all layers of an application. You might as well be asking which layer represents the repository layer while you're at it. You can add oth

MVC does not comprise all layers of an application. You might as well be asking which layer represents the repository layer while you're at it. You can add other layers and frameworks in addition to using MVC. That doesn't mean MVC is pointless.

samatman 7y ago
This strikes me as a good argument for the MOVE paradigm discussed in the Fine Article. 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.
- wwweston 7y ago
  Seems to me that what people usually think of as the "Model" layer actually has "Operations", but we usually call them "methods." 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. )
  - samatman 7y ago
    It's reifying Events that attracts me to this model. This would encourage a message-passing style, which has always been a big win for me when I adopt it. 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.
jolmg 7y ago
> MVC does not comprise all layers of an application. 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.
Aeolun 7y ago
MVRCS A Model View Repository Controller Service framework!

samatman 7y ago

This strikes me as a good argument for the MOVE paradigm discussed in the Fine Article. 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.

wwweston 7y ago
Seems to me that what people usually think of as the "Model" layer actually has "Operations", but we usually call them "methods." 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. )
- samatman 7y ago
  It's reifying Events that attracts me to this model. This would encourage a message-passing style, which has always been a big win for me when I adopt it. 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.

jolmg 7y ago

> MVC does not comprise all layers of an application. 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.

Aeolun 7y ago

MVRCS A Model View Repository Controller Service framework!