You can read here about multiple views, from the audio unit programming guide, towards the bottom of the page:
I have tested some commercial plug-ins and some allow for multiple views .
On a related but separate area, correct me if I am wrong, but the view can get a pointer to the controller through getOwnedFilter(). It can then use a lock to get/set things directly in the model. In the audio unit specification it states:
"You build a view to be logically separate from the audio unit executable code, yet packaged within the same bundle. To achieve this programmatic separation, Apple recommends that you develop your custom views so that they would work running in a separate address space, in a separate process, and on a separate machine from the audio unit executable code. For example, you pass data between the audio unit executable code and its view only by value, never by reference.
Without impinging on this formal separation, however, it’s often convenient to share a header file between an audio unit executable code and its view. You’ll see this done in the SDK’s FilterDemo project. A shared header file can provide, for example, data types and constants for custom properties that an audio unit’s executable code and its view can both use."
I have also been looking at DSSI, http://dssi.sourceforge.net/ , where the messaging system between the view and the controller is done totally using OSC, which allows a view to be running on a different computer.
While it is impossible to future proof yourself against what the hosts may through up in the future, I do think that there is something like views running on different computers coming up fairly soon. I am still new to JUCE and Audio Unit programming so any view (pardon the pun) on this would be greatly appreciated!