Hi! When using custom dialog windows in a MVVM application, do you think it´s Ok to use the code behind to handle properties, events etc.? Or should I always have a ViewModel binded to every dialog view? What´s your thought?
+1
A:
The reasons for having a ViewModel on a dialog are pretty much the same as those for having them on any other kind of window as far as I'm concerned, so I'd do the same thing (whatever that is!). Personally, I'd have the ViewModel and as little as possible in the code behind.
Grant Crofton
2010-07-20 14:39:18
Yes this is my thought to. But I got a little bit unsure when looking at some applications that people made, that uses the codebehind for dialogs instead of it´s corresponding ViewModel.
Lunetics
2010-07-20 14:46:12
+1
A:
By which criterion should we decide whether code-behind is OK or not?
What if the custom dialog is a complex wizard? What if the dialog is an entire mini-application in its own right? In those cases I think we can argue that MVVM is worthwhile, and code-behind really isn't very attractive.
If we accept that, then where do we draw the line? I think we shouldn't, because a dialog which is simple today may become complex in the future. It would be better to stay consistent.
In other words: MVVM all the way
See also this related question: http://stackoverflow.com/questions/1023995/mvvm-and-commands-that-show-more-gui
Mark Seemann
2010-07-20 14:40:23
+1
A:
A dialog is just another view. The primary purpose of the ViewModel is to encapsulate the behavior of the view. If that said view has behavior, than a ViewModel is warranted, in my opinion. If it is a static UI, or simply bound directly to a model item without any coded behavior, than no, a ViewModel is not necessary.
Brian Genisio
2010-07-21 02:04:12
A:
Why not to use a ViewModel for a dialog?
The ViewModel sample application of the WPF Application Framework (WAF) shows how to use WPF dialogs together with ViewModels.
jbe
2010-07-23 19:01:32