It is perfectly right to have ViewModel contains ViewModel. Actually that is the recommended practice: To have one main ViewModel for the whole page, the main ViewModel could contain ViewModels for the sub views in the page.
Sally Xu
Software Engineer
Aprimo, Inc
Please remember to mark the replies as answers if they answered your question
If I have a main ViewModel for the whole page, and the main ViewModel contains ViewModels for the sub views in the page, who should then be responsible for newing up the sub ViewModels? I can create instances of the sub viewmodels in the the main viewmodel
and bind this to the DataContext property on the child views, like I show in my original post. The problem with this is that if you open one of the sub views in the designer it will not have a DataContext and it is not possible to create designtime data. If
I instead new up the ViewModel for a subview as a resource in the subview, it will be easy to create design time data, but I can't see how I would then attach this viewmodel to the main viewmodel?
Please click the "Mark as answer" link if this answered your question
The pattern I enjoy the most uses MEF (Managed Extensibility Framework) which is available for both Silverlight 3 and 4. In MEF, you can define the ViewModel independently of the view and simply import it. This is very powerful because typically I'll create
a master view model with "global" information and connections to services, then a base view model that imports the master. Since the sub view models are based on the master, they have access to that information. Then the views themselves simply import the
models and the engine handles newing them up and cascading the dependencies. You can view my blog for more examples on that.
Thank you! MEF looks very interesting. I have already looked at it, but the deadline for the project I am working on is to close to bring in a complete new framework. It would take to much time for me to master it completly. But I guess what I am facing
here is a common problem? Someone must have solved this using only plain mvvm (no prism or mef)?
Please click the "Mark as answer" link if this answered your question
nyhetsgruppe...
Participant
1429 Points
392 Posts
Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 05, 2010 03:07 PM | LINK
Hi,
If I have a view which is composed of other views like this:
<Grid x:Name="LayoutRoot">
<StackPanel>
<views:View1 />
<views:View2 />
</StackPanel>
</Grid>
Is it bad practice to reference the ViewModels for View1 and View2 in the main viewmodel like this?
<Grid x:Name="LayoutRoot">
<StackPanel>
<views:View1 DataContext="{Binding Path=View1ViewModel}" />
<views:View2 DataContext="{Binding Path=View2ViewModel}" />
</StackPanel>
</Grid>
Is this okay, or is it bad practive for a viewmodel to reference other viewmodels?
Roger Gullhaug
sladapter
All-Star
43609 Points
7910 Posts
Re: Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 05, 2010 03:17 PM | LINK
It is perfectly right to have ViewModel contains ViewModel. Actually that is the recommended practice: To have one main ViewModel for the whole page, the main ViewModel could contain ViewModels for the sub views in the page.
Software Engineer
Aprimo, Inc
Please remember to mark the replies as answers if they answered your question
nyhetsgruppe...
Participant
1429 Points
392 Posts
Re: Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 05, 2010 03:20 PM | LINK
Thank you:)
Roger Gullhaug
nyhetsgruppe...
Participant
1429 Points
392 Posts
Re: Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 09, 2010 08:25 AM | LINK
A follow up question to this...
If I have a main ViewModel for the whole page, and the main ViewModel contains ViewModels for the sub views in the page, who should then be responsible for newing up the sub ViewModels? I can create instances of the sub viewmodels in the the main viewmodel and bind this to the DataContext property on the child views, like I show in my original post. The problem with this is that if you open one of the sub views in the designer it will not have a DataContext and it is not possible to create designtime data. If I instead new up the ViewModel for a subview as a resource in the subview, it will be easy to create design time data, but I can't see how I would then attach this viewmodel to the main viewmodel?
Roger Gullhaug
Jeremy Likness
Contributor
3308 Points
530 Posts
Re: Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 09, 2010 12:05 PM | LINK
The pattern I enjoy the most uses MEF (Managed Extensibility Framework) which is available for both Silverlight 3 and 4. In MEF, you can define the ViewModel independently of the view and simply import it. This is very powerful because typically I'll create a master view model with "global" information and connections to services, then a base view model that imports the master. Since the sub view models are based on the master, they have access to that information. Then the views themselves simply import the models and the engine handles newing them up and cascading the dependencies. You can view my blog for more examples on that.
nyhetsgruppe...
Participant
1429 Points
392 Posts
Re: Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 09, 2010 12:13 PM | LINK
Thank you! MEF looks very interesting. I have already looked at it, but the deadline for the project I am working on is to close to bring in a complete new framework. It would take to much time for me to master it completly. But I guess what I am facing here is a common problem? Someone must have solved this using only plain mvvm (no prism or mef)?
Roger Gullhaug
nyhetsgruppe...
Participant
1429 Points
392 Posts
Re: Mvvm - bad practice to reference a viewmodel from another viewmodel?
Mar 12, 2010 09:04 AM | LINK
I found the answer to this if anyone should be intrested. The solution is to use the d:DataContext and d:DesignInstance design properties.
http://karlshifflett.wordpress.com/2009/10/28/ddesigninstance-ddesigndata-in-visual-studio-2010-beta2/
Roger Gullhaug