4 ms·

Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated rea

Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. That aside, lots of people in the web world have a sort of "Operation" layer in MVC but call them a "service". Deciding to use events is another architectural decision some people make even in web MVC. But you can take or leave any piece of this stuff and I feel like you don't need a new acronym for every combination of architectural decisions.

rumanator 7y ago
> Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. It seems you're mixing up implementation details with the actual design pattern. It makes no difference if you implement MVC with events or objects or imperative programming. The only thing that matters to a design pattern is the pattern, and the pattern is how three components interact to drive an user interface.
daotoad 7y ago
BILASM! But I Like Acronyms So Much. Web "MVC" rarely was really MVC. Except that it changed the meaning of the term. https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?WhatsaControllerAnyway https://wiki.c2.com/?WhatsaControllerAnyway
alexis_fr 7y ago
Then the web came, and we have the MVCS+JS+REST mess. Explanation: Model: The Javabean View: The HTML Controller: Whatever Java code that calls the service layers, Service: The services in the lower layer, JS: Since you have js with your HTML, then the JS also acts kind of like a controller for complex parts of the UI, REST: Well that’s a second entry point to your service layer, to which the JS transmits Events (as in MOVE) that cannot be managed by a page reload. It’s a back channel unknown to the Controller. So perhaps React has a point ;)

rumanator 7y ago

> Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application. It seems you're mixing up implementation details with the actual design pattern. It makes no difference if you implement MVC with events or objects or imperative programming. The only thing that matters to a design pattern is the pattern, and the pattern is how three components interact to drive an user interface.

daotoad 7y ago

BILASM! But I Like Acronyms So Much. Web "MVC" rarely was really MVC. Except that it changed the meaning of the term. https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?ModelViewControllerHistory https://wiki.c2.com/?WhatsaControllerAnyway https://wiki.c2.com/?WhatsaControllerAnyway

alexis_fr 7y ago

Then the web came, and we have the MVCS+JS+REST mess. Explanation: Model: The Javabean View: The HTML Controller: Whatever Java code that calls the service layers, Service: The services in the lower layer, JS: Since you have js with your HTML, then the JS also acts kind of like a controller for complex parts of the UI, REST: Well that’s a second entry point to your service layer, to which the JS transmits Events (as in MOVE) that cannot be managed by a page reload. It’s a back channel unknown to the Controller. So perhaps React has a point ;)