I've just recently completed a personal project and one technique I did use to break down the interface was to have one main Model View Controller that was handling a lot of the main logic of the application. Then for the most part, there were many generic controls lets say a Slider and a Text Field that were bound together to a single float value. They themselves would make up another (Model View Controller) that the parent Model View Controller would interact with. Though the communication would allays be down hill, never self reflecting loop.
So in general, The controller would interact with the controller of the Slider and textField that were bound together. But both did not have access directly to each others view, so when a event did occur for the Controller of the Text field and slider it would be handled by the parent controller that would handle most of the logical flow of the program then down to the controller of the slider and text field.
This worked great and got a lot of great responses of the users who used the application and loved the flex ability it did bring with very logical re-adjusting controls that they didn't have to think.
Though the developer in me questions the pragmatism and purity of the design. The design of the system was a top town approach that I took from this Adobe post cast:
Adobe, general algorithms http://www.youtube.com/watch?v=4moyKUHApq4
,and generally usage of using MVC as objects inside objects reflected this instead of one global MVC controller.
And suggestions where i could improve in the next project or should i use this same approach again?