4 ms·

The problems lie in the way change notifications are managed. Any reasonably complex client application will have multiple data sources feeding into a myriad of

The problems lie in the way change notifications are managed. Any reasonably complex client application will have multiple data sources feeding into a myriad of components, with a very entangled dependency graph. In MVC, you’ll start sharing models and notifying changes selectively, with a lot of “action at a distance” from component interactions triggering updates. This is usually hard to visualize and debug (worst case, recursive update loops). In Flux/redux the unidirectional nature comes from all updates targeting and emanating from a single source (store), and being routed to views accordingly. An interaction from one component will never result in a disconnect where you failed to update the correct model(s) or to notify the right components of a change (hi Backbone.js).

mpweiher 8y ago
> Any reasonably complex client application will > have multiple data sources feeding into a myriad of components, Why? Certainly my MVC apps have a single "store" that's the source of truth, and I would say that what you describe is not following the MVC pattern.
- ricardobeat 8y ago
  You're gonna have to provide a bit more context for that. What part of the MVC pattern?
  - mpweiher 8y ago
    Various parts. First, the M->V communication should only notify, the View decides if and when to refresh itself, and the action it takes is only to refresh itself. "In this metaphor, views deal with everything graphical; they request data from their model, and display the data."[1] Also, the View should only make a note that it needs to be refreshed (Cocoa for example has the convenient "needsDisplay" boolean property on Views), not actually do the refresh on notification. I see the latter a lot, so you have the model effectively calling refresh on the view, so pushing updates. That ain't MVC, in MVC the View pulls from the model. "The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes some input action and the active controller notifies the model to change itself accordingly. The model carries out the prescribed operations, possibly changing its state, and broadcasts to its dependents (views and controllers) that it has changed, possibly telling them the nature of the change. Views can then inquire of the model about its new state, and update their display if necessary."[1] Once you're down with pushing updates, you tend to also see "optimizations" that also push the data to the view (very much what the linked article describes). Again, not MVC, View pulls, model doesn't push. If the view only refreshes itself and pulls from the model when notified, it's hard to get an entangled dependency graph, and downright impossible to get loops. So if you get loops, you're definitely not doing MVC. As to the "multiple sources" feeding into a "myriad of components", that also doesn't quite match. In MVC, all sources feed into the model. When the model changes, it sends its change notification, and it doesn't really matter where the original change came from, the action afterward is the same. So if "multiple sources" are causing you problems, that is a strong indicator that you are not doing MVC, and "myriad of components" also indicates that you don't have a strongly developed model. [1] https://web.archive.org/web/20100921030808/http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf https://web.archive.org/web/20100921030808/http://www.itu.dk...

mpweiher 8y ago

> Any reasonably complex client application will > have multiple data sources feeding into a myriad of components, Why? Certainly my MVC apps have a single "store" that's the source of truth, and I would say that what you describe is not following the MVC pattern.

ricardobeat 8y ago
You're gonna have to provide a bit more context for that. What part of the MVC pattern?
- mpweiher 8y ago
  Various parts. First, the M->V communication should only notify, the View decides if and when to refresh itself, and the action it takes is only to refresh itself. "In this metaphor, views deal with everything graphical; they request data from their model, and display the data."[1] Also, the View should only make a note that it needs to be refreshed (Cocoa for example has the convenient "needsDisplay" boolean property on Views), not actually do the refresh on notification. I see the latter a lot, so you have the model effectively calling refresh on the view, so pushing updates. That ain't MVC, in MVC the View pulls from the model. "The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes some input action and the active controller notifies the model to change itself accordingly. The model carries out the prescribed operations, possibly changing its state, and broadcasts to its dependents (views and controllers) that it has changed, possibly telling them the nature of the change. Views can then inquire of the model about its new state, and update their display if necessary."[1] Once you're down with pushing updates, you tend to also see "optimizations" that also push the data to the view (very much what the linked article describes). Again, not MVC, View pulls, model doesn't push. If the view only refreshes itself and pulls from the model when notified, it's hard to get an entangled dependency graph, and downright impossible to get loops. So if you get loops, you're definitely not doing MVC. As to the "multiple sources" feeding into a "myriad of components", that also doesn't quite match. In MVC, all sources feed into the model. When the model changes, it sends its change notification, and it doesn't really matter where the original change came from, the action afterward is the same. So if "multiple sources" are causing you problems, that is a strong indicator that you are not doing MVC, and "myriad of components" also indicates that you don't have a strongly developed model. [1] https://web.archive.org/web/20100921030808/http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf https://web.archive.org/web/20100921030808/http://www.itu.dk...