3 ms·

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

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.
- sunir 1y ago
  The model is the source of truth. For almost all apps, it should always be valid. (For those apps that isn’t true such as massively distributed systems, it should present a projection of what can be considered valid to your locality and handle delta internally.) There has to be a boundary that controls changes to the model. The confusion with MVC is where is the best place for this boundary. Well more than one place as it turns out because there are at least two models of reality trying to converge. The model itself and the view of the model (and the user’s mind). The view’s job is to present a projection of the model and then collect change events to the model. Thus could be a UX or an API. Other events can also change the model like say sensor data. The controller decides what view to show and retrieves model data to project and translates change events coming from the external world (views or events) into changes the model should interpret. This includes gatekeeping such as auth, and error handling. That’s a lot for one class so it can get confusing very quickly. Why localize it in one place? So viewtrollers come around where the controller is in the view class but in the onhandle methods. This also makes sense since each view has a mini controller to handle all the jiggling bits. This works well when there are no orthogonal injections like auth or eventing. When those are added it makes sense ins viewtroller to extend the model with controller functionality to for eg control authorization or have a thin event receiver to fsm in the model. This all works but three years later it’s hard to figure out when I read the code again. So I have learnt to treat the model as pure data as much as possible and the view as much about rendering as possible. Views can have little controllers for handling the jiggling. What the controller cares about is when a change to the system needs to happen. Then I can put the system control fsm in one place. I can put all event handling in the same fsm to avoid race conditions. The goal is to make it easier to reason about. What I don’t want are multiple threads of fsms in conflict with each other.

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.

sunir 1y ago
The model is the source of truth. For almost all apps, it should always be valid. (For those apps that isn’t true such as massively distributed systems, it should present a projection of what can be considered valid to your locality and handle delta internally.) There has to be a boundary that controls changes to the model. The confusion with MVC is where is the best place for this boundary. Well more than one place as it turns out because there are at least two models of reality trying to converge. The model itself and the view of the model (and the user’s mind). The view’s job is to present a projection of the model and then collect change events to the model. Thus could be a UX or an API. Other events can also change the model like say sensor data. The controller decides what view to show and retrieves model data to project and translates change events coming from the external world (views or events) into changes the model should interpret. This includes gatekeeping such as auth, and error handling. That’s a lot for one class so it can get confusing very quickly. Why localize it in one place? So viewtrollers come around where the controller is in the view class but in the onhandle methods. This also makes sense since each view has a mini controller to handle all the jiggling bits. This works well when there are no orthogonal injections like auth or eventing. When those are added it makes sense ins viewtroller to extend the model with controller functionality to for eg control authorization or have a thin event receiver to fsm in the model. This all works but three years later it’s hard to figure out when I read the code again. So I have learnt to treat the model as pure data as much as possible and the view as much about rendering as possible. Views can have little controllers for handling the jiggling. What the controller cares about is when a change to the system needs to happen. Then I can put the system control fsm in one place. I can put all event handling in the same fsm to avoid race conditions. The goal is to make it easier to reason about. What I don’t want are multiple threads of fsms in conflict with each other.