6 ms·

Any implementation of MVC I've seen the V and the C are so tightly coupled the separation seemed artificial. Skill issue?

by lukasb 1y ago

andrewflnr 1y ago
Yeah, it's really hard to tease them apart in a GUI sort of environment, since the input is so tightly tied to the graphical view. Model and View have always seemed pretty obvious to me but I've never gotten a compelling answer as to what a controller is. My best guess from this article, given then "associated by observer" link from View to Controller, is that the View is supposed to pass events to the Controller, which will interpret them into changes to the Model. But what's the format of these events that's both meaningfully separate from the View, e.g. could be emitted from different views to maybe different controllers, but doesn't just force the View to do most of the work we want the Controller to do?
- to11mtm 1y ago
  At least in my head, the 'controller' is what can either take 0 or more parameters or input models as 'input' and the controller can either provide direction to the browser as to what to do next. e.x. in a 'proper' ASP.NET MVC 4 project I 'inherited', the View took input data in and with a tiny bit of JS magic/razor fuckery around the query page etc, but overall the controllers would return the right hints for the Razor/JS 'view' to move the application flow along or otherwise do a proper reload.
  - grugagag 1y ago
    In ASP.NET MVC is a modified version of classical MVC adapted for the web. The Controller in ASP.NET MVC takes on the role of both the classic Controller and part of the classic Model's role (orchestrating the retrieval/updating of data). The connection between the View and the Model is completely severed and mediated by the Controller.
    - to11mtm 1y ago
      Well I put it the way I did because I've also seen it done wrong (i.e. razor views pulling stuff from DB more directly because razor)
- skydhash 1y ago
  Controller is where your logic is. Your model is your state, and the view is presentation. Both are static. The controller is the dynamic aspect that update the view to match the state and update the state according to interaction or some other system events. Splitting the logic from the state and presentation make the code very testable. You can either have the state as input and you test your presentation, or have the presentation as input (interaction and lifecycle events) and test your state (or its reflection in the presentation). Also this decoupling makes everything more flexible. You can switch your presentation layer or alter the mechanism for state storage and retrieval (cache, sync) without touching your logic.
  - dsego 1y ago
    In the server-side web world the controller should ideally only receive http actions and call services or fat models. It should have no business logic, only validation and parsing. In the frontend UI world the controller is bound to UI events and communicates those from the view to the model objects. (1). (1) https://github.com/madhadron/mvc_for_the_web https://github.com/madhadron/mvc_for_the_web
    - gf000 1y ago
      Though it's probably easiest understood in a non-web world. The web makes it quite a bit more involved with a separation of client- and server-side state - plus you have a given frontend "framework" in the shape of DOM, which people often leave out of the picture. This latter necessities the 'escape hatches' in React and alia.
  - js8 1y ago
    I always thought that business logic, expressed in the language of your domain, should be part of the model. The controller is just a translator from the language of keystrokes and mouseclicks into the domain language, and the view is just a translator from the domain language into pieces of text and widgets to display to the user.
  - mpweiher 1y ago
    > Controller is where your logic is. That's actually precisely the anti-pattern. Massive View Controller is an example of this. The Model is where your logic is. Everything that is in any way semantically relevant. Views handled display and editing (yes, also editing!). Controllers ... well ... I guess you might have a need for them.
- mjevans 1y ago
  Agreed, but maybe my mental model is splitting the 'Controller' aspect into the client / server model. Everything must get validated server side, there's no other rational choice. Otherwise you cannot enforce any consistency or business logic. That just leaves formatting the requested changes into a language the server model accepts. Maybe model is more 'database', controller is API interface (server side + client request requirements), and view is end user render?
bitwize 1y ago
Early Microsoft frameworks (the old Windows 3.x and 9x era MFC) suggested using a "document-view" model wherein the model was a "document" class serviced by a "view" class which handled presentation and UI, serving as both view and controller. There were wizards that would spit out skeletons for these classes and everything.

Any implementation of MVC I've seen the V and the C are so tightly coupled the separation seemed artificial. Skill issue?

by lukasb 1y ago

Any implementation of MVC I've seen the V and the C are so tightly coupled the separation seemed artificial. Skill issue?

andrewflnr 1y ago

Yeah, it's really hard to tease them apart in a GUI sort of environment, since the input is so tightly tied to the graphical view. Model and View have always seemed pretty obvious to me but I've never gotten a compelling answer as to what a controller is. My best guess from this article, given then "associated by observer" link from View to Controller, is that the View is supposed to pass events to the Controller, which will interpret them into changes to the Model. But what's the format of these events that's both meaningfully separate from the View, e.g. could be emitted from different views to maybe different controllers, but doesn't just force the View to do most of the work we want the Controller to do?

to11mtm 1y ago
At least in my head, the 'controller' is what can either take 0 or more parameters or input models as 'input' and the controller can either provide direction to the browser as to what to do next. e.x. in a 'proper' ASP.NET MVC 4 project I 'inherited', the View took input data in and with a tiny bit of JS magic/razor fuckery around the query page etc, but overall the controllers would return the right hints for the Razor/JS 'view' to move the application flow along or otherwise do a proper reload.
- grugagag 1y ago
  In ASP.NET MVC is a modified version of classical MVC adapted for the web. The Controller in ASP.NET MVC takes on the role of both the classic Controller and part of the classic Model's role (orchestrating the retrieval/updating of data). The connection between the View and the Model is completely severed and mediated by the Controller.
  - to11mtm 1y ago
    Well I put it the way I did because I've also seen it done wrong (i.e. razor views pulling stuff from DB more directly because razor)
skydhash 1y ago
Controller is where your logic is. Your model is your state, and the view is presentation. Both are static. The controller is the dynamic aspect that update the view to match the state and update the state according to interaction or some other system events. Splitting the logic from the state and presentation make the code very testable. You can either have the state as input and you test your presentation, or have the presentation as input (interaction and lifecycle events) and test your state (or its reflection in the presentation). Also this decoupling makes everything more flexible. You can switch your presentation layer or alter the mechanism for state storage and retrieval (cache, sync) without touching your logic.
- dsego 1y ago
  In the server-side web world the controller should ideally only receive http actions and call services or fat models. It should have no business logic, only validation and parsing. In the frontend UI world the controller is bound to UI events and communicates those from the view to the model objects. (1). (1) https://github.com/madhadron/mvc_for_the_web https://github.com/madhadron/mvc_for_the_web
  - gf000 1y ago
    Though it's probably easiest understood in a non-web world. The web makes it quite a bit more involved with a separation of client- and server-side state - plus you have a given frontend "framework" in the shape of DOM, which people often leave out of the picture. This latter necessities the 'escape hatches' in React and alia.
- js8 1y ago
  I always thought that business logic, expressed in the language of your domain, should be part of the model. The controller is just a translator from the language of keystrokes and mouseclicks into the domain language, and the view is just a translator from the domain language into pieces of text and widgets to display to the user.
- mpweiher 1y ago
  > Controller is where your logic is. That's actually precisely the anti-pattern. Massive View Controller is an example of this. The Model is where your logic is. Everything that is in any way semantically relevant. Views handled display and editing (yes, also editing!). Controllers ... well ... I guess you might have a need for them.
mjevans 1y ago
Agreed, but maybe my mental model is splitting the 'Controller' aspect into the client / server model. Everything must get validated server side, there's no other rational choice. Otherwise you cannot enforce any consistency or business logic. That just leaves formatting the requested changes into a language the server model accepts. Maybe model is more 'database', controller is API interface (server side + client request requirements), and view is end user render?

bitwize 1y ago

Early Microsoft frameworks (the old Windows 3.x and 9x era MFC) suggested using a "document-view" model wherein the model was a "document" class serviced by a "view" class which handled presentation and UI, serving as both view and controller. There were wizards that would spit out skeletons for these classes and everything.