4 ms·

"Everyone who has done MVC long enough... The controller should have and only have logic which absolutely cannot be moved to a service layer." Sorry, which let

by jerf 7y ago

"Everyone who has done MVC long enough... The controller should have and only have logic which absolutely cannot be moved to a service layer." Sorry, which letter in MVC is the "service layer"? One of the reasons I don't buy into MVC is that MVC doesn't mean anything any more, and hasn't ever since the web people got their hands on it. If you ask ten developers what MVC is and get 13 different answers (see half the sibling replies to this comment), well, that's not itself a problem, but it does mean that running around telling people that they should or should not do "MVC" has been pointless for a long time. I still like MVC for its original purpose: Multiple views in a CAD/CAM program. Makes perfect sense there. I don't think I've yet seen a place where it belongs other than that, though.

nck4222 7y ago
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!
ampdepolymerase 7y ago
If you had to build e.g. Google Maps from the ground up, how would you architecture the frontend?
- ReptileMan 7y ago
  With the ability to measure straight line distance between two points not hidden and afterthought.
- cfv 7y ago
  CQRS comes to mind. spam events from user interaction, respond to them with any number of disjoint event handlers, with a tiny core runtime that ultimately acts on a specific subset of those events destined to modify the DOM in some way or another
- jerf 7y ago
  Assuming you are implicitly claiming it only makes sense to use MVC, it couldn't be MVC, because as I said in my other reply, network communication is too big a concern to just slip in to the design. It's a fundamental change. MVC doesn't have any provisions for network in it. One of my major objections to the concept is the way people think good design == MVC and MVC == good design. I could describe to you my architecture, but then someone stuck in the MVC mindset would see my discussion of how the UI controls will drive the map object, and say "AH HA! Aren't you saying that the map is a View and the UI controls are the Controller?" To which my reply is, if MVC describes everything, and you can squeeze anything into it if you squint hard enough, it describes nothing, because that makes everything "MVC" and therefore you can't distinguish the quality of a design by whether it is or is not MVC if everything is MVC. On the other hand, if MVC isn't everything, but is in fact a very precisely specified combination of OO patterns, then no, my Google maps design would not be MVC, because I would not use the MVC patterns as my guideline in the slightest and the odds the resulting design would happen to conform to the strict definition by the end of the project approach 0, even if you could pick out bits and pieces that sort of seem to resemble it sometimes kinda sorta. I don't "avoid" models, views, or controllers, but I never chase them.
rumanator 7y ago
> Sorry, which letter in MVC is the "service layer"? Your question, sarcasm and all, makes no sense and either reflects bad faith or ignorance. The model in MVC is the model, even if it depends on the service layer or not. Design patterns describe components with respect to their roles, and the fact that the concept of service is not necessary to explain the design pattern that does not mean it should be in the acronym. In fact, models are quite obviously wrappers around repositories/gateways/services/etc etc etc. The reason behind this, obviously, is that if your goal is to simply provide a UI then it makes absolutely no sense to drag or leak the application or service layer into the interface. You just add an adapter to the repositories/gateways/services and then use that adapter to input and output the data you need to be in the UI. > One of the reasons I don't buy into MVC is that MVC doesn't mean anything any more, That cop-out doesn't cut it. MVC is well documented, and objectively defined. Just because some people either ignore its meaning or get a bit "creative" with their personal definition (I'm looking at you, Qt) it doesn't mean there is no concrete definition, or that you have any excuse to criticise something you don't know.
- tabtab 7y ago
  Re: MVC is well documented, and objectively defined. I'm skeptical. Do you have a link or quote of the "official" definition so we can critique it?
  - rumanator 7y ago
    For example: http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf The pattern is known for having been made popular by Smalltalk. In the 1980s. It makes no sense to assume that a design pattern that has been widely used for, say, 40 years is somehow not described.
    - tabtab 7y ago
      I still haven't found anything that makes a clear distinction between "controller" and "model". The best explanation I've ever heard is that a controller's job is to map UI activity to the proper model and view. That's a start, but there is a lot of grey area there also as determining such can sometimes be complex in itself, which leaves the door open to "fat" controllers.
derefr 7y ago
It doesn't really matter what MVC "is", but it's very important where MVC goes—MVC, in the https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa... sense, belongs to one particular "adapter." MVC is not the framework of your application; it's the framework of your application's $foo adapter, where $foo can be "web" or "native UI toolkit" or "GRPC API." Sometimes a whole application looks to be done in an MVC style; in those cases, the "application"—i.e. all the business-logic mechanism, though not necessarily all the policy controlling it—is probably some upstream thing written by a third party (e.g. someone else's API; someone else's DBMS; someone else's game engine), and the repo consists entirely of your adapter for that application. CRUD apps, of course, really are just a reshaping of an RDBMS's DML (INSERT, UPDATE, DELETE) API, so MVC (on top of an RDBMS) really is a 100% solution to CRUD problems.
tobr 7y ago
> I still like MVC for its original purpose: Multiple views in a CAD/CAM program. Makes perfect sense there. That sounds intriguing. Could someone expand a little on it? Why is MVC more suitable for that particular problem?

by jerf 7y ago

nck4222 7y ago

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!

ampdepolymerase 7y ago

If you had to build e.g. Google Maps from the ground up, how would you architecture the frontend?

ReptileMan 7y ago
With the ability to measure straight line distance between two points not hidden and afterthought.
cfv 7y ago
CQRS comes to mind. spam events from user interaction, respond to them with any number of disjoint event handlers, with a tiny core runtime that ultimately acts on a specific subset of those events destined to modify the DOM in some way or another
jerf 7y ago
Assuming you are implicitly claiming it only makes sense to use MVC, it couldn't be MVC, because as I said in my other reply, network communication is too big a concern to just slip in to the design. It's a fundamental change. MVC doesn't have any provisions for network in it. One of my major objections to the concept is the way people think good design == MVC and MVC == good design. I could describe to you my architecture, but then someone stuck in the MVC mindset would see my discussion of how the UI controls will drive the map object, and say "AH HA! Aren't you saying that the map is a View and the UI controls are the Controller?" To which my reply is, if MVC describes everything, and you can squeeze anything into it if you squint hard enough, it describes nothing, because that makes everything "MVC" and therefore you can't distinguish the quality of a design by whether it is or is not MVC if everything is MVC. On the other hand, if MVC isn't everything, but is in fact a very precisely specified combination of OO patterns, then no, my Google maps design would not be MVC, because I would not use the MVC patterns as my guideline in the slightest and the odds the resulting design would happen to conform to the strict definition by the end of the project approach 0, even if you could pick out bits and pieces that sort of seem to resemble it sometimes kinda sorta. I don't "avoid" models, views, or controllers, but I never chase them.

rumanator 7y ago

> Sorry, which letter in MVC is the "service layer"? Your question, sarcasm and all, makes no sense and either reflects bad faith or ignorance. The model in MVC is the model, even if it depends on the service layer or not. Design patterns describe components with respect to their roles, and the fact that the concept of service is not necessary to explain the design pattern that does not mean it should be in the acronym. In fact, models are quite obviously wrappers around repositories/gateways/services/etc etc etc. The reason behind this, obviously, is that if your goal is to simply provide a UI then it makes absolutely no sense to drag or leak the application or service layer into the interface. You just add an adapter to the repositories/gateways/services and then use that adapter to input and output the data you need to be in the UI. > One of the reasons I don't buy into MVC is that MVC doesn't mean anything any more, That cop-out doesn't cut it. MVC is well documented, and objectively defined. Just because some people either ignore its meaning or get a bit "creative" with their personal definition (I'm looking at you, Qt) it doesn't mean there is no concrete definition, or that you have any excuse to criticise something you don't know.

tabtab 7y ago
Re: MVC is well documented, and objectively defined. I'm skeptical. Do you have a link or quote of the "official" definition so we can critique it?
- rumanator 7y ago
  For example: http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf The pattern is known for having been made popular by Smalltalk. In the 1980s. It makes no sense to assume that a design pattern that has been widely used for, say, 40 years is somehow not described.
  - tabtab 7y ago
    I still haven't found anything that makes a clear distinction between "controller" and "model". The best explanation I've ever heard is that a controller's job is to map UI activity to the proper model and view. That's a start, but there is a lot of grey area there also as determining such can sometimes be complex in itself, which leaves the door open to "fat" controllers.

derefr 7y ago

It doesn't really matter what MVC "is", but it's very important where MVC goes—MVC, in the https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa... sense, belongs to one particular "adapter." MVC is not the framework of your application; it's the framework of your application's $foo adapter, where $foo can be "web" or "native UI toolkit" or "GRPC API." Sometimes a whole application looks to be done in an MVC style; in those cases, the "application"—i.e. all the business-logic mechanism, though not necessarily all the policy controlling it—is probably some upstream thing written by a third party (e.g. someone else's API; someone else's DBMS; someone else's game engine), and the repo consists entirely of your adapter for that application. CRUD apps, of course, really are just a reshaping of an RDBMS's DML (INSERT, UPDATE, DELETE) API, so MVC (on top of an RDBMS) really is a 100% solution to CRUD problems.

tobr 7y ago

> I still like MVC for its original purpose: Multiple views in a CAD/CAM program. Makes perfect sense there. That sounds intriguing. Could someone expand a little on it? Why is MVC more suitable for that particular problem?