3 ms·
That's not the issue. Whether its being pushed or pulled isn't relevant at all either. The issue is when your views start pushing changes to the models and you
by jeremiep 11y ago
That's not the issue. Whether its being pushed or pulled isn't relevant at all either.
The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. This is the control-flow equivalent of letting a thousands ping-pong balls loose and trying to predict where each and every one of them will end up.
I don't think its "MVC vs new fancy techs" as you make it sound but rather adding constraints to MVC in order to make it scale.
- mpweiher 11y ago>The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. No. You can only get into a recursive cascade of updates if your model pushes changes to the views in response to changes occurring on the model. Otherwise the two are decoupled. In a typical MVC app, there are at least two phases: first you react to events and make updates to the model and send out change-notifications that invalidate those parts of the view(s) that represent the bits that have changed. In a second phase, you update the bits of the view(s) that were invalidated. Repeat. No update cycles, as long as you only invalidate in the first phase, and only repaint in the second phase. EDIT: The temptation is huge to "optimize" this process by having the invalidation notification do the actual work of repainting. That's where you get into trouble, you need to keep it decoupled.