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