Click here to Skip to main content
15,886,771 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Hi all,

I'm implementing my first Silverlight 3 application by using the MVVM pattern and I have some questions about it.

Is it possible to nest a view model within a view model? It's the case in which I have a main page which stores multiple user controls, each one in a different application area, or the case in which I want to store based view model properties that may be accessed to other view models.

Can a view model be created as a stand alone view model, so not linked to a model? It's the case in which I need to create a menu dynamically with data already loaded within the application, or input data coming from the application's caller.

Thanks.

Regards.
Posted
Updated 24-Aug-10 8:19am
v2
Comments
Keith Barrow 21-Aug-10 9:40am    
Reason for my vote of 5
Good Question

Is it possible to nest a view model within a view model?

Yes: Just create a property of the view model type. A really good idea is to have an IViewModel (which inherits from INotifyPropertyChanged ) and an abstract ViewModel base class. You can even make the child view model property in the main view model class of type IViewModel so it'll take any type you like.

Can a view model created as a stand alone view model, so not linked to a model?



Yes, it just breaks the pattern. It is probably better to have a model to create the menu information outside of the view model, as this de-couples the task of displaying the menu from creating the menu, but YMMV on this last point.
 
Share this answer
 
v2
Comments
Nish Nishant 21-Aug-10 9:29am    
Reason for my vote of 5
Proposed answer.
Keith Barrow 21-Aug-10 9:39am    
Thanks!
You might also want to consider using Microsoft Prism[^].

Any view consisting of another view could actually be broken up into sub regions within regions thus breaking your complex view into smaller ones. You will need to have a look at the Prism documentation and understand it before you start using though.
 
Share this answer
 
Yes, it just breaks the pattern. It is probably better to have a model to create the menu information outside of the view model, as this de-couples the task of displaying the menu from creating the menu, but YMMV on this last point.


The issue here is that most of the menu is built statically an dynamic part is built with data which comes as input in the Silverlight application. So I thought that menu view model may not be linked to a model because related to the UI only. That view model may be used associated with a model in the future for those menus that are built entirely from a source, such as XML or DB.

Also, is view model responsibility to work on the model and or Business Object in a Line of Business application? That's why I adopted to create this command from a view model not linked to a model in this case.
Otherwise, I would create the model, than the view model to be bound to the view in the main view model, which I think it's more tricky and resource expensive in this case.

Thanks.

 
Share this answer
 
v2
Sorry,

I would need other information.

I have the following cases:
- A main view having a child view.
- the main view model having the child view model of the child view as public property.

If I bind the DataContext of the child view to the child view model property from the XAML of the parent view, I get the following error:

Unknown attribute DataContext on element...


How can I solve it? Should I set the DataContext in the code behind of the parent view?

Thanks.
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900