Sorry to bump this old dead thread, but I may have something useful to contribute.
While there is nothing specifically in JUCE to help you implement a model/view/controller paradigm, there is nothing in there that prevents you from doing it either. In particular, I have found it helpful to implement an MVC system with JUCE for the following reasons.
First, on my project, the interactions between each of the controls are subtle. Changing one control somewhere can have an effect on superficially unrelated controls in other windows. Having a central model and one controller simplifies this complexity greatly.
Second, there is a great deal of state in my application. It is difficult to serialize the entire state of a JUCE application to a single file and load it again easily. Ideally, there would be a function that would walk the entire hierarchy and record the state of each control, so that JUCE applications could save their state at exit time and restore it when the application is relaunched. Without an MVC system, this is hard to implement; with an MVC system, it’s trivial.
Now since JUCE itself is pretty much a system of Views, it’s not necessary to create a separate View abstraction. But I created a Model class and a Controller class. The Model is responsible for containing all state for my app. It also contains all necessary mutexes as well as ChangeBroadcasters for each of the fields that might affect a change to any JUCE control, but it doesn’t implement any actions except for simple accessors and locking functions. The Controller class is the only class that is friend (in a C++ sense) to the Model, and has access to its internals. All operations on the Model state must go through the Controller. Thus all commands and other effects must be implemented as Controller methods.
Implementing MVC is much simplified if you introduce a bunch of ChangeBroadcasters into your Model class for every field that any JUCE widget needs to be notified about a change. For each relevant field in the Model, you create a corresponding ChangeBroadcaster. Then, you make each interested display widget a ChangeListener that wants to be notified about updates to the Model. Then all of those widgets know exactly the right time to repaint themselves.
I only permit changes to the Model class to occur through the Controller. This reduces locking contention from my highly multithreaded app.
If I had understood JUCE’s hierarchy a little better, I would have made all the Controller’s effects be UndoableActions, which would have let me create an Undo command for my app. Ah the benefits of hindsight…
Hope these breadcrumbs help other people in similar situations.