>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.
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.