5 ms·

> 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 M

> 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.
    - johnmaguire2013 7y ago
      I think the biggest distinction to me is that the controller is the entry-point into an action/routine. It takes external inputs and returns an output to be sent back downstream.
      - tabtab 7y ago
        That's pretty much true of any function or method.
        johnmaguire2013 7y ago
        Yes, but I'm talking about into the overall system, not into a method.
        justanotherc 7y ago
        In many frameworks the controller isn't even the entrypoint anymore though. Laravel for example has a separate router layer, which is the entrypoint that then passes things into a controller.
        tabtab 7y ago
        If the controller doesn't fulfill that job, then the model or view model would (for good or bad).
  - ptx 7y ago
    The problem is just that other later GUI frameworks didn't follow that design. Smalltalk had a controller for each view to handle user input, but Windows doesn't and neither does GTK, Qt or Swing. As Martin Fowler says[1] in his a GUI architecture overview: "As Smalltalk developed in the 80's and 90's this led to some significant variations on the classic MVC model. Indeed one could almost say that MVC disappeared, if you consider the view/controller separation to be an essential part of MVC - which the name does imply." [1] https://martinfowler.com/eaaDev/uiArchs.html https://martinfowler.com/eaaDev/uiArchs.html
- brlewis 7y ago
  Wikipedia is generally good at choosing and citing "official" sources: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...
jerf 7y ago
"MVC is well documented, and objectively defined." In that case, almost nothing called MVC is MVC. For one thing, MVC has no network component to it, so anything involving client/server is automatically not using MVC, which immediately whacks what appears to be 90% of the claimed uses to me. A network layer is too important to the design of a program to just slip it in between one of the M-V or V-C or M-C layers as if it's no big deal. I also personally consider it a critical component of MVC that it is the normal case that there are many-to-many relationships between all of the components, because otherwise, the pattern is pointlessly complicated for no gain. But it's very normal to have MVC where almost all, if not simply, all of the VC relationships are 1-to-1. You don't really have "MVC" if you have multiply-used models, but the VC element is degenerate in every use. It isn't particularly uncommon to have 1-to-1 relationships between the models either, although it is certainly the case that the models are most often reused. But then you just have data objects, not "MVC". MVC works in CAD/CAM and similar situations, and is somewhere between "uselessly complicated" to "nonfunctional" in almost every other use case it has been ported to. (Jamming it in where it isn't necessary may "work", but is hardly a win for the pattern. Having "M" is not enough to have MVC.) Or, the term has stretched to the point where it's just useless.
jimbokun 7y ago
"MVC is well documented, and objectively defined." Yes, many times, in many mutually incompatible ways.
ricardobeat 7y ago
I have never heard this description of M in MVC > models are quite obviously wrappers around repositories/gateways/services/etc

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.
  - johnmaguire2013 7y ago
    I think the biggest distinction to me is that the controller is the entry-point into an action/routine. It takes external inputs and returns an output to be sent back downstream.
    - tabtab 7y ago
      That's pretty much true of any function or method.
      - johnmaguire2013 7y ago
        Yes, but I'm talking about into the overall system, not into a method.
        justanotherc 7y ago
        In many frameworks the controller isn't even the entrypoint anymore though. Laravel for example has a separate router layer, which is the entrypoint that then passes things into a controller.
        tabtab 7y ago
        If the controller doesn't fulfill that job, then the model or view model would (for good or bad).
- ptx 7y ago
  The problem is just that other later GUI frameworks didn't follow that design. Smalltalk had a controller for each view to handle user input, but Windows doesn't and neither does GTK, Qt or Swing. As Martin Fowler says[1] in his a GUI architecture overview: "As Smalltalk developed in the 80's and 90's this led to some significant variations on the classic MVC model. Indeed one could almost say that MVC disappeared, if you consider the view/controller separation to be an essential part of MVC - which the name does imply." [1] https://martinfowler.com/eaaDev/uiArchs.html https://martinfowler.com/eaaDev/uiArchs.html
brlewis 7y ago
Wikipedia is generally good at choosing and citing "official" sources: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...

jerf 7y ago

"MVC is well documented, and objectively defined." In that case, almost nothing called MVC is MVC. For one thing, MVC has no network component to it, so anything involving client/server is automatically not using MVC, which immediately whacks what appears to be 90% of the claimed uses to me. A network layer is too important to the design of a program to just slip it in between one of the M-V or V-C or M-C layers as if it's no big deal. I also personally consider it a critical component of MVC that it is the normal case that there are many-to-many relationships between all of the components, because otherwise, the pattern is pointlessly complicated for no gain. But it's very normal to have MVC where almost all, if not simply, all of the VC relationships are 1-to-1. You don't really have "MVC" if you have multiply-used models, but the VC element is degenerate in every use. It isn't particularly uncommon to have 1-to-1 relationships between the models either, although it is certainly the case that the models are most often reused. But then you just have data objects, not "MVC". MVC works in CAD/CAM and similar situations, and is somewhere between "uselessly complicated" to "nonfunctional" in almost every other use case it has been ported to. (Jamming it in where it isn't necessary may "work", but is hardly a win for the pattern. Having "M" is not enough to have MVC.) Or, the term has stretched to the point where it's just useless.

jimbokun 7y ago

"MVC is well documented, and objectively defined." Yes, many times, in many mutually incompatible ways.

ricardobeat 7y ago

I have never heard this description of M in MVC > models are quite obviously wrappers around repositories/gateways/services/etc