So how do you display complex aggregated ViewModels whose Models have relations to each other?
NO wpf disciple ever spoke about that, guess why its not possible...
Do you think thats true?
Don`t understand me?
Look: A CustomerViewModel has many OrderViewModel and those many ProductViewModel.
You have 3 Workspaces to enter the new data for all 3 ViewModels AND you have 3 listboxes/combobo/datagrid to multiselect Collections of type => customerVMs, orderVMs and productVM`s.
That the UI makes sense to the user he should not need to turn off/on the workspace every new customer/order/product is added what is a bad user experience, how do you do this typical LOB application requirement?
EDIT:
You have in MVVM a Collection of type WorkSpace. Every ViewModel can be a Workspace because it derives from WorkSpace class. The Workspaces collection is bound to a ItemsSource afair josh smith example.
Statement: I want to use goold mature windows forms user interfaces no closable viewmodels... Problem: MVVM can only work with workspaces (closable doesnt matter...) because a CustomerviewModel must already be instantiated and then added to the workspaces collection bound to the itemsControl and datatemplated depending on the datatype.
If I would have no Workspaces which hold my ViewModel instances I could not datatemplate them, because a ViewModel in MVVM takes a model as constructor parameter. DataTemplating a UserControl with DataType of the CustomerViewModel will throw a Exception in XAML!
Now look at my UI I want to have: I have no workspaces but 3 ViewModels = 3 UserControls datatemplated means 3 times a big bang...
You get now why I do not like MVVM? Its not well thought and I search for a solution...
Of course I could put my ViewModels aka DataFormulars in a ObservableCollection but I do not want them to be bound to an ItemsControl. I want that these 3 UserControl have a certain position in my layout. with an ItemsControl you have a stupid queue where a new Dataformular is just added and wrapped if it doesnt fit into the existing space. Thats is all rubbish layout design/bad UI.
You get me now?
You can easily have multiple controls in a Window, each bound to a different ViewModel. To coordinate between the VMs, a typical approach is to loosely couple the different components together using message passing. For instance, your Customer ViewModel may send a message saying that you've selected an Order and then your OrderViewModel (visualized as a control in part of your main window, perhaps) will see the message and change the displayed Order.
You can accomplish something similar with a shared service class that exposes an interface which you inject into each of your VMs. You can then bind the properties of this shared interface to allow the VMs to communicate, much the same way as with messages. I've used something similar to this to represent a "SelectedObject" concept, where a wide range of different object types could be selected and different VMs in my app have different ways they might like to visualize that. For instance, using your example, if a Product became the SelectedObject, you might have a "detail" panel that now renders the Product using some standard ProductDataTemplate and perhaps another panel (displaying the Order) would change the SelectedItem on a Products list. You can easily have multiple 'workspaces' and all of them stay in sync with eachother by virtue of the set of properties or messages that the VMs use to collaborate.