A few newb MVVM (WPF) questions...
-
Say I have a dialog with a list box and 3 buttons: Add, Edit and Delete. The listbox displays a list of Widget objects. I'm assuming the "proper MVVM way" is to do something like: class ViewModel { public ObservableCollection Widgets { ... }; public Command AddCommand { ... }; public Command EditCommand { ... }; public Command DeleteCommand { ... }; } Add then the ListBox.ItemsSource binds to Widgets, the Add button to AddCommand, Edit to EditCommand and so on... Now is where I get confused on MVVM... 1) Typical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas? 2) Obviously, Edit and Delete need to be disabled if no item is selected. I know how to do that the "non MVVM" way, but what is the MVVM way? I know the command has a CanExecute handler. Should all that logic happen in there? It would seem I would either need the list box or the selected item and the collection. I guess I'm just trying to figure out where the line should be drawn at which code goes in the code behind and which goes in the view model. I understand MVVM "purists" say ZERO code in the code behind, but it seems to me like you'll be creating a lot of properties, commands, etc and jumping through a lot of hoops to have all the bindable properties in the view model.
-
Say I have a dialog with a list box and 3 buttons: Add, Edit and Delete. The listbox displays a list of Widget objects. I'm assuming the "proper MVVM way" is to do something like: class ViewModel { public ObservableCollection Widgets { ... }; public Command AddCommand { ... }; public Command EditCommand { ... }; public Command DeleteCommand { ... }; } Add then the ListBox.ItemsSource binds to Widgets, the Add button to AddCommand, Edit to EditCommand and so on... Now is where I get confused on MVVM... 1) Typical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas? 2) Obviously, Edit and Delete need to be disabled if no item is selected. I know how to do that the "non MVVM" way, but what is the MVVM way? I know the command has a CanExecute handler. Should all that logic happen in there? It would seem I would either need the list box or the selected item and the collection. I guess I'm just trying to figure out where the line should be drawn at which code goes in the code behind and which goes in the view model. I understand MVVM "purists" say ZERO code in the code behind, but it seems to me like you'll be creating a lot of properties, commands, etc and jumping through a lot of hoops to have all the bindable properties in the view model.
- If there are certain situations you dont want the command to execute, the command should have a CanExecute property which can be set. 2) You achieve this through binding the enabled property of the command button to a property in your view model. This property should implement
INotifyPropertyChanged. This property is then set to false triggering anINotifywhich will disable the button. Hope this makes sesnse. :)
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick Visit the Hindi forum here.
modified on Monday, October 18, 2010 3:01 AM
- If there are certain situations you dont want the command to execute, the command should have a CanExecute property which can be set. 2) You achieve this through binding the enabled property of the command button to a property in your view model. This property should implement
-
Say I have a dialog with a list box and 3 buttons: Add, Edit and Delete. The listbox displays a list of Widget objects. I'm assuming the "proper MVVM way" is to do something like: class ViewModel { public ObservableCollection Widgets { ... }; public Command AddCommand { ... }; public Command EditCommand { ... }; public Command DeleteCommand { ... }; } Add then the ListBox.ItemsSource binds to Widgets, the Add button to AddCommand, Edit to EditCommand and so on... Now is where I get confused on MVVM... 1) Typical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas? 2) Obviously, Edit and Delete need to be disabled if no item is selected. I know how to do that the "non MVVM" way, but what is the MVVM way? I know the command has a CanExecute handler. Should all that logic happen in there? It would seem I would either need the list box or the selected item and the collection. I guess I'm just trying to figure out where the line should be drawn at which code goes in the code behind and which goes in the view model. I understand MVVM "purists" say ZERO code in the code behind, but it seems to me like you'll be creating a lot of properties, commands, etc and jumping through a lot of hoops to have all the bindable properties in the view model.
We have implemented an observable list, a selected item and an editable item. The editable item is used as a throw away object to support the user cancelling an edit. I also find I refresh a list from the database after a CRUD operation on one of the items. Getting all the related data for a complex item is a pita. Say if you add a chair and want the room, apartment, floor, building information on the chair object (as with a view) then getting all those items is tedious. Although I may be doing this quite wrong!
Never underestimate the power of human stupidity RAH
-
Say I have a dialog with a list box and 3 buttons: Add, Edit and Delete. The listbox displays a list of Widget objects. I'm assuming the "proper MVVM way" is to do something like: class ViewModel { public ObservableCollection Widgets { ... }; public Command AddCommand { ... }; public Command EditCommand { ... }; public Command DeleteCommand { ... }; } Add then the ListBox.ItemsSource binds to Widgets, the Add button to AddCommand, Edit to EditCommand and so on... Now is where I get confused on MVVM... 1) Typical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas? 2) Obviously, Edit and Delete need to be disabled if no item is selected. I know how to do that the "non MVVM" way, but what is the MVVM way? I know the command has a CanExecute handler. Should all that logic happen in there? It would seem I would either need the list box or the selected item and the collection. I guess I'm just trying to figure out where the line should be drawn at which code goes in the code behind and which goes in the view model. I understand MVVM "purists" say ZERO code in the code behind, but it seems to me like you'll be creating a lot of properties, commands, etc and jumping through a lot of hoops to have all the bindable properties in the view model.
SledgeHammer01 wrote:
I understand MVVM "purists" say ZERO code in the code behind
Gah. That's just zealotry and stupidity rolled into one honking great pile of doggy poo. If the code doesn't touch on the model, there's no need to move it out of the view, e.g. you are updating a complex visual. Typically, you'd have a SelectedItem in the VM and you'd simply have the CanExecute check to see if it's the default value or not.
SledgeHammer01 wrote:
ypical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas?
The VM should be there to support the view, so it exposes the behaviour that's appropriate for the view. I can't think of many instances where I've wanted to share one VM among different views so this may not be a real issue for you.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
-
SledgeHammer01 wrote:
I understand MVVM "purists" say ZERO code in the code behind
Gah. That's just zealotry and stupidity rolled into one honking great pile of doggy poo. If the code doesn't touch on the model, there's no need to move it out of the view, e.g. you are updating a complex visual. Typically, you'd have a SelectedItem in the VM and you'd simply have the CanExecute check to see if it's the default value or not.
SledgeHammer01 wrote:
ypical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas?
The VM should be there to support the view, so it exposes the behaviour that's appropriate for the view. I can't think of many instances where I've wanted to share one VM among different views so this may not be a real issue for you.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
Hehe... Ok, so if putting code in the code behind of a view is "allowed" in MVVM, what exactly is the point? I'll use my earlier example of a listbox and 3 buttons Add, Edit and Delete. Add is pretty much going to be a call to _model.Add(), delete is pretty much going to be a call to _model.Delete(), edit is pretty much going to be a call to _model.Update() or whatever. So, I would design my data access layer well and have add, edit and delete functionality THERE, not some chinsy view model. Now I don't mean put GUI stuff in the data access layer, but in my real world application, I have a data access layer that is something like: public class Widget : INotifyPropertyChanged { } public class Widgets :System.Collections.IEnumerable, INotifyCollectionChanged { } So in this case, the view model would simply do something like: public Widgets { get { return GetService().Widgets; } } that seems like adding a middle man class just for the hell of it doesn't it? I know I have seen some MVVM samples where the data access layer does NOT implement INotifyPropertyChanged and they do it in the VM... but to me that is hella retarded. I shouldn't need to re-implement INPC in every view model that consumes the data access layer objects. So now the viewmodel seems to be a light weight redirection to the data store. Just to NOT have to put "listBox.ItemsSource = GetService().Widgets;" in the code behind? See, thats what I haven't wrapped my head around yet... trying to figure out what the hell the VM actually gives you in a real world application. I guess if you don't have a well designed data access layer it would make sense... but not having a well designed data access layer seems like a much bigger issue to me :). Thoughts? I'm seriously trying to figure this thing out.
-
Hehe... Ok, so if putting code in the code behind of a view is "allowed" in MVVM, what exactly is the point? I'll use my earlier example of a listbox and 3 buttons Add, Edit and Delete. Add is pretty much going to be a call to _model.Add(), delete is pretty much going to be a call to _model.Delete(), edit is pretty much going to be a call to _model.Update() or whatever. So, I would design my data access layer well and have add, edit and delete functionality THERE, not some chinsy view model. Now I don't mean put GUI stuff in the data access layer, but in my real world application, I have a data access layer that is something like: public class Widget : INotifyPropertyChanged { } public class Widgets :System.Collections.IEnumerable, INotifyCollectionChanged { } So in this case, the view model would simply do something like: public Widgets { get { return GetService().Widgets; } } that seems like adding a middle man class just for the hell of it doesn't it? I know I have seen some MVVM samples where the data access layer does NOT implement INotifyPropertyChanged and they do it in the VM... but to me that is hella retarded. I shouldn't need to re-implement INPC in every view model that consumes the data access layer objects. So now the viewmodel seems to be a light weight redirection to the data store. Just to NOT have to put "listBox.ItemsSource = GetService().Widgets;" in the code behind? See, thats what I haven't wrapped my head around yet... trying to figure out what the hell the VM actually gives you in a real world application. I guess if you don't have a well designed data access layer it would make sense... but not having a well designed data access layer seems like a much bigger issue to me :). Thoughts? I'm seriously trying to figure this thing out.
Think about it from a slightly different perspective. Suppose that you have a page transition that doesn't have any reliance on a model, but is highly complex - where would you put the code for the trigger points in this? Would it make sense to put it in a ViewModel? Obviously not. Now, suppose that your application has to interact with a model, this is where the VM comes into play. Stop thinking in terms of it being an unnecessary middleman - it's not, it's a vital layer in protecting and coordinating changes to your model. Most of the samples that you have seen tend to be fairly simplistic, with perhaps a single table being updated - this is not the way that it works in real life situations. Model interactions tend to be highly complex, with a single view potentially interacting with multiple model parts. The VM is vital for coordinating this. What people seem to get hung up on is that the VM simply seems to exist to provide details of INPC - this is not an accurate viewpoint (it's just that INPC plays an important part in updating the view). With a VM, you can isolate the logic of the view from the XAML that forms the view - which means that it becomes easier to test the application as you can test the VM without worrying about the view. From a developers POV, the VM also allows you to decouple the design part of the application from the logic of the application, giving designers a chance to work with the code without having to have any knowledge about how to code themselves.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
-
Think about it from a slightly different perspective. Suppose that you have a page transition that doesn't have any reliance on a model, but is highly complex - where would you put the code for the trigger points in this? Would it make sense to put it in a ViewModel? Obviously not. Now, suppose that your application has to interact with a model, this is where the VM comes into play. Stop thinking in terms of it being an unnecessary middleman - it's not, it's a vital layer in protecting and coordinating changes to your model. Most of the samples that you have seen tend to be fairly simplistic, with perhaps a single table being updated - this is not the way that it works in real life situations. Model interactions tend to be highly complex, with a single view potentially interacting with multiple model parts. The VM is vital for coordinating this. What people seem to get hung up on is that the VM simply seems to exist to provide details of INPC - this is not an accurate viewpoint (it's just that INPC plays an important part in updating the view). With a VM, you can isolate the logic of the view from the XAML that forms the view - which means that it becomes easier to test the application as you can test the VM without worrying about the view. From a developers POV, the VM also allows you to decouple the design part of the application from the logic of the application, giving designers a chance to work with the code without having to have any knowledge about how to code themselves.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
Hmmm... well, I guess in the cases where you need to "repackage" data from your DAL, it makes some sense. You could unit test your "repackaging" code. Maybe one (or more) of my assumptions are incorrect? A "Model" is a data object, correct? My data provider assembly is a collection of "Models" and all the (non GUI) APIs to create, edit and delete them from the database. All the objects in my data provider assembly implement IPNC. There is ZERO GUI code in there. The sole purpose of that assembly is to package the database data in a C# friendly way and hide everybody and everything from database calls. Nobody touches the database directly. It all goes through the data provider APIs. Any multi-threading, coordination, protection, etc. happens in here. The viewmodel knows nothing about the view? The view is coupled to the view model (through the DataContext and binding the properties)? Right now, the majority of my views bind directly to DAL objects... I do have maybe 1 or 2 views where I had to "repackage" the data from the DAL so I could bind to it. Or maybe add a GUI state option, etc. So for example, if I had a list of Widgets and I wanted to put that into a listbox, obviously it would be retarded to put the checkbox state in the DAL, so it would be repackaged in the view model. I guess I can understand that... But in the cases where you are pretty much binding directly to DAL object? I guess I've also read about people saying its kind of necessary to open your XAML in Expression Blend. Maybe it is... to be honest, I haven't tried opening my views in there in a long long time. Sorry, maybe it sounds like I am trying to avoid MVVM. I'm not. I'm trying to understand its real thought process :).
-
Hmmm... well, I guess in the cases where you need to "repackage" data from your DAL, it makes some sense. You could unit test your "repackaging" code. Maybe one (or more) of my assumptions are incorrect? A "Model" is a data object, correct? My data provider assembly is a collection of "Models" and all the (non GUI) APIs to create, edit and delete them from the database. All the objects in my data provider assembly implement IPNC. There is ZERO GUI code in there. The sole purpose of that assembly is to package the database data in a C# friendly way and hide everybody and everything from database calls. Nobody touches the database directly. It all goes through the data provider APIs. Any multi-threading, coordination, protection, etc. happens in here. The viewmodel knows nothing about the view? The view is coupled to the view model (through the DataContext and binding the properties)? Right now, the majority of my views bind directly to DAL objects... I do have maybe 1 or 2 views where I had to "repackage" the data from the DAL so I could bind to it. Or maybe add a GUI state option, etc. So for example, if I had a list of Widgets and I wanted to put that into a listbox, obviously it would be retarded to put the checkbox state in the DAL, so it would be repackaged in the view model. I guess I can understand that... But in the cases where you are pretty much binding directly to DAL object? I guess I've also read about people saying its kind of necessary to open your XAML in Expression Blend. Maybe it is... to be honest, I haven't tried opening my views in there in a long long time. Sorry, maybe it sounds like I am trying to avoid MVVM. I'm not. I'm trying to understand its real thought process :).
Sorry - I've just got round to reading your post. Right, in the case where you are just packaging data through to the model, there is no need to recreate the element in the VM. There are techniques you can use to parcel the call across though, and these exist in the VM - here's a post that explains one mechanism (link[^]). Something you might want to consider though, is that the VM is also the point at which you need to sanitise your data before it gets committed to the database. Suppose that you want the user to enter a value between 1 and 10 - but you have to use a textbox for it; the VM should handle the validation to ensure that the data is reasonable. It has to protect the DAL.
I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be
Forgive your enemies - it messes with their heads
-
Say I have a dialog with a list box and 3 buttons: Add, Edit and Delete. The listbox displays a list of Widget objects. I'm assuming the "proper MVVM way" is to do something like: class ViewModel { public ObservableCollection Widgets { ... }; public Command AddCommand { ... }; public Command EditCommand { ... }; public Command DeleteCommand { ... }; } Add then the ListBox.ItemsSource binds to Widgets, the Add button to AddCommand, Edit to EditCommand and so on... Now is where I get confused on MVVM... 1) Typical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas? 2) Obviously, Edit and Delete need to be disabled if no item is selected. I know how to do that the "non MVVM" way, but what is the MVVM way? I know the command has a CanExecute handler. Should all that logic happen in there? It would seem I would either need the list box or the selected item and the collection. I guess I'm just trying to figure out where the line should be drawn at which code goes in the code behind and which goes in the view model. I understand MVVM "purists" say ZERO code in the code behind, but it seems to me like you'll be creating a lot of properties, commands, etc and jumping through a lot of hoops to have all the bindable properties in the view model.
- It took me a while (and I still forget) that the view model is only used to present the state of the model to the view. You shouldn't have to worry about "everyone using the view model" because if it was for a different view, then you could create another view model without that CurrentItem property. For my first MVVM app I put way too much model related logic into the view model, and it really muddies the water. 2) Have you seen the RelayCommand? Even if you're not using MVVM-Light (which is a nice framework) it should point you in the right direction. I've found learning MVVM is a lot like learning IoC/DI, you kind of have to re-learn the way you think about approaching and composing an application. Have you figured out dialog messages? That took me a while to grok :)
-
Say I have a dialog with a list box and 3 buttons: Add, Edit and Delete. The listbox displays a list of Widget objects. I'm assuming the "proper MVVM way" is to do something like: class ViewModel { public ObservableCollection Widgets { ... }; public Command AddCommand { ... }; public Command EditCommand { ... }; public Command DeleteCommand { ... }; } Add then the ListBox.ItemsSource binds to Widgets, the Add button to AddCommand, Edit to EditCommand and so on... Now is where I get confused on MVVM... 1) Typical Add button behavior is to auto select the new item. How would that happen? It was suggested to me that ViewModel expose a "CurrentItem" property for **2-way** data binding with the listbox. The AddCommand handler would update the CurrentItem after it creates it. Is this a good idea? To me, that seems hokey as it would force that behavior on everybody using the view model. Also, it would set that property in situations where it may not want to be set. Any ideas? 2) Obviously, Edit and Delete need to be disabled if no item is selected. I know how to do that the "non MVVM" way, but what is the MVVM way? I know the command has a CanExecute handler. Should all that logic happen in there? It would seem I would either need the list box or the selected item and the collection. I guess I'm just trying to figure out where the line should be drawn at which code goes in the code behind and which goes in the view model. I understand MVVM "purists" say ZERO code in the code behind, but it seems to me like you'll be creating a lot of properties, commands, etc and jumping through a lot of hoops to have all the bindable properties in the view model.
I too often wondered about things like this. But I have finally come to terms that I think makes the most sense. 1) Go ahead and use the CurrentItem and force that behavior on the ViewModel. I think the hard fact is that ViewModels shouldn't be used across different presentation frameworks (e.g. WebForms, Asp.Net MVC, Windows Forms, WPF). This shouldn't happen for a multitude of reasons. The major point is your going to paint yourself into a very difficult and hard to use ViewModel to try and achieve compatibility with all of these frameworks. I have often fought with this too, and I came to some really good conclusions trying to learn the real way to treat ViewModels. * ViewModels work best as an organizational structure. I treat ViewModels as an organization unit and not another technical layer of abstractions. This will give you optimal productivity and fewer bugs. With a well structured and organized ViewModel you create a more maintainable and agile product base. You shouldn't think about using ViewModels in "other" places than the one your creating it for, because it just doesn't work well. * ViewModel code should be very simple. This means that the ViewModel code should be very simple that even a 2 year old can write them. Sure you can have a ViewModelBase class that contains some important infrastructure for your application, but after that your ViewModel code should be simple. With really simple viewmodel code, you can write up a ViewModel for exactly what you need in a few minutes. Now, i know what some people are going to complain saying that they want to have a single ViewModel for everything. But with a focused and really simple to write ViewModels. It's painless to create more classes for your program to do exactly what you need. Does this mean that your going to have a lot of ViewModels? YES. Does this mean you have to write a ViewModel for Windows Forms and a different one for WPF? YES If you think ViewModels should be another component of re-use, please take a look at this post from Udi about the fallacy of re-use. http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/[^] 2) For the Commands, I like to use the RelayCommand implementation: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx#id0090030[