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?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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: MVVM and commands that show more GUI