MVVM Recommendations
-
I'm in the middle of designing a WPF app that is going to have a view with a lot of information. It is a sort of Management Console for an app that we are developing. I am envisioning some sort of tabbed interface to organize all of the various "things" that this UI has to deal with. The model part is fairly straightforward; it is going to be accessing an SQL database with lots of different tables. I am wondering if the "standard" way of doing things would be to create one large view model class that worked with the overall view, or if it is more appropriate to treat each tab like a separate view, with a separate view model for each? Or does that add needless complexity? Or does it even really matter? :confused: Thanks for any advice on the matter. :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I'm in the middle of designing a WPF app that is going to have a view with a lot of information. It is a sort of Management Console for an app that we are developing. I am envisioning some sort of tabbed interface to organize all of the various "things" that this UI has to deal with. The model part is fairly straightforward; it is going to be accessing an SQL database with lots of different tables. I am wondering if the "standard" way of doing things would be to create one large view model class that worked with the overall view, or if it is more appropriate to treat each tab like a separate view, with a separate view model for each? Or does that add needless complexity? Or does it even really matter? :confused: Thanks for any advice on the matter. :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Definitely each tab should be its own view and have its own VM. There is no view for managing the tabs per se. Its more of a control that data binds to a collection of views or VMs. Typically it'll bind to a collection of VMs and you'll use DataTemplates to map a View to the VMs and the "control" will auto create the view and wire up the data context, etc. Personally though, I find that backwards as I like to launch a view and have the xaml specify what the VM is through a ViewLocator.
-
I'm in the middle of designing a WPF app that is going to have a view with a lot of information. It is a sort of Management Console for an app that we are developing. I am envisioning some sort of tabbed interface to organize all of the various "things" that this UI has to deal with. The model part is fairly straightforward; it is going to be accessing an SQL database with lots of different tables. I am wondering if the "standard" way of doing things would be to create one large view model class that worked with the overall view, or if it is more appropriate to treat each tab like a separate view, with a separate view model for each? Or does that add needless complexity? Or does it even really matter? :confused: Thanks for any advice on the matter. :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
I'm doing the exact same thing right now. My app has tabs, and on each tab I add & remove user controls at runtime. So it's basically "nested' views. The MainWindowViewModel is responsible for creating the view and viewmodel and handling commands. I created a TabInfo class. The MainWindowViewModel maintians a collection of TabInfo object. I then use that to manage the tabs.
Everything makes sense in someone's mind
-
Definitely each tab should be its own view and have its own VM. There is no view for managing the tabs per se. Its more of a control that data binds to a collection of views or VMs. Typically it'll bind to a collection of VMs and you'll use DataTemplates to map a View to the VMs and the "control" will auto create the view and wire up the data context, etc. Personally though, I find that backwards as I like to launch a view and have the xaml specify what the VM is through a ViewLocator.
Thanks for the feedback. I'm seriously considering using DevForce A/F to help me out. http://drc.ideablade.com/xwiki/bin/view/Documentation/devforce-caliburn[^] [Edit:] I'm thinking that if we ever decided we needed a web interface, I could leverage the Silverlight support in the above with minimal code changes.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I'm doing the exact same thing right now. My app has tabs, and on each tab I add & remove user controls at runtime. So it's basically "nested' views. The MainWindowViewModel is responsible for creating the view and viewmodel and handling commands. I created a TabInfo class. The MainWindowViewModel maintians a collection of TabInfo object. I then use that to manage the tabs.
Everything makes sense in someone's mind
Cool. Thanks for the feedback! :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I'm in the middle of designing a WPF app that is going to have a view with a lot of information. It is a sort of Management Console for an app that we are developing. I am envisioning some sort of tabbed interface to organize all of the various "things" that this UI has to deal with. The model part is fairly straightforward; it is going to be accessing an SQL database with lots of different tables. I am wondering if the "standard" way of doing things would be to create one large view model class that worked with the overall view, or if it is more appropriate to treat each tab like a separate view, with a separate view model for each? Or does that add needless complexity? Or does it even really matter? :confused: Thanks for any advice on the matter. :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Each tab should be a separate view / view model and you should be plugging in /removing views on demand. There is no concept of creating one large view model that works for all views.
Thanks. That seems to be the general consensus. Sorry if it was a stupid question.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Thanks. That seems to be the general consensus. Sorry if it was a stupid question.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Tom Delany wrote:
Sorry if it was a stupid question
There is no such thing as a stupid question :) Only stupid answers. If you are unsure, it is always better to ask.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
Tom Delany wrote:
Sorry if it was a stupid question
There is no such thing as a stupid question :) Only stupid answers. If you are unsure, it is always better to ask.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
Thanks
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Thanks. That seems to be the general consensus. Sorry if it was a stupid question.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I'm in the middle of designing a WPF app that is going to have a view with a lot of information. It is a sort of Management Console for an app that we are developing. I am envisioning some sort of tabbed interface to organize all of the various "things" that this UI has to deal with. The model part is fairly straightforward; it is going to be accessing an SQL database with lots of different tables. I am wondering if the "standard" way of doing things would be to create one large view model class that worked with the overall view, or if it is more appropriate to treat each tab like a separate view, with a separate view model for each? Or does that add needless complexity? Or does it even really matter? :confused: Thanks for any advice on the matter. :)
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
IMHO ... If each tab in your tabbed interface is, essentially, stand alone, and could be presented in a different way (say in a tree view, or pop-up form etc.) then you need to model that view using a view model. the fact that a particular View attached to that view model happens to sit on a tab control somewhere is 'nothing to do with' the ViewModel. OTOH if the separation into tabs is more just a gui convenience (that is, all the tabs are necessary and inter-related) then the ViewModel should model all of the controls on all of the tabs - and the View just 'happens' to split them into tabs. Some other implementation may decide to present all of the data in one large, scrolling form, for example, still bound to the single view model. this isn't a criticism, as I do it myself, but I believe one of the aims of using ViewModels is that you try to design the ViewModel first rather than thinking 'I want a tabbed interface' you think 'I want to perform these functions." The ViewModel contains the data to be presented/updated, and offers the functionality - then you design the view to be able to provide the interface to the user. So in the case of the 'Management Console' style, i would think you would have several ViewModels, one for each piece of functionality, and a ManagementConsoleViewmodel that has, as properties, each of the view models it requires to perform its functionality. The View that binds to the 'big' view model may place the smaller views on tabs, in trees, or on the sides of an animated 3D spinning cube - by binding to its view model it has access to all it needs regardless, and each of the smaller viewmodels can also be viewed in whatever way you want - and indeed can also be used independently if required.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
IMHO ... If each tab in your tabbed interface is, essentially, stand alone, and could be presented in a different way (say in a tree view, or pop-up form etc.) then you need to model that view using a view model. the fact that a particular View attached to that view model happens to sit on a tab control somewhere is 'nothing to do with' the ViewModel. OTOH if the separation into tabs is more just a gui convenience (that is, all the tabs are necessary and inter-related) then the ViewModel should model all of the controls on all of the tabs - and the View just 'happens' to split them into tabs. Some other implementation may decide to present all of the data in one large, scrolling form, for example, still bound to the single view model. this isn't a criticism, as I do it myself, but I believe one of the aims of using ViewModels is that you try to design the ViewModel first rather than thinking 'I want a tabbed interface' you think 'I want to perform these functions." The ViewModel contains the data to be presented/updated, and offers the functionality - then you design the view to be able to provide the interface to the user. So in the case of the 'Management Console' style, i would think you would have several ViewModels, one for each piece of functionality, and a ManagementConsoleViewmodel that has, as properties, each of the view models it requires to perform its functionality. The View that binds to the 'big' view model may place the smaller views on tabs, in trees, or on the sides of an animated 3D spinning cube - by binding to its view model it has access to all it needs regardless, and each of the smaller viewmodels can also be viewed in whatever way you want - and indeed can also be used independently if required.
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
Sorry for the slow reply. My father passed away on the date that you sent this to me and I had to leave town suddenly. Thank you for the advice. I appreciate it. :) I do not in fact take your comments as criticism. In actuality, I have been trying to code up the view models first, but in parallel I have also been trying to get some idea what the view will end up looking like. As you say, it may indeed end up looking completely different that a tabbed interface. If I construct the view models properly (and that's a big if), I should be able to swap in any sort of views that I desire with minimal fuss.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
Sorry for the slow reply. My father passed away on the date that you sent this to me and I had to leave town suddenly. Thank you for the advice. I appreciate it. :) I do not in fact take your comments as criticism. In actuality, I have been trying to code up the view models first, but in parallel I have also been trying to get some idea what the view will end up looking like. As you say, it may indeed end up looking completely different that a tabbed interface. If I construct the view models properly (and that's a big if), I should be able to swap in any sort of views that I desire with minimal fuss.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
Tom Delany wrote:
My father passed away on the date that you sent this to me and I had to leave town suddenly.
My sympathies - not a good time. :rose:
Tom Delany wrote:
If I construct the view models properly (and that's a big if),
yes - that's the problem I faced many times! I actually split my ViewModel and ViewData into separate classes - as I find this makes more sense (to me, anyway!) so my model really models the functionality to be presented, and the data is just the data that allows that functionality to occur. It allowed me more flexiblity to do what I wanted to do but it may not suit you! Cheers
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')