Scenario.
- ViewModel has a property
State
. - View has a ComboBox that allows to change value of
State
. - ViewModel needs to run some validation (call
bool ValidateState(State value)
method) before setting value ofState
property.
Question.
How would you implement it?
My concerns.
- I want my solution to be generic so I could use it in different similar scenarios. For example in scenario where
ValidateState()
is anasync
method. - I do not want change value of
State
in ViewModel unless I 100% sure it's valid. - If new value of
State
is not accepted (is not valid) I want ComboBox to keep having the old value as selected.
Disclaimer. I know there are multiple ways of implementing it. Also I'm not a MVVM novice. I would like to discuss which solution you think better suits this scenario and possibly discuss pros and cons of it.
Best Answer
You could implement INotifyPropertyChanged interface and use the setters to perform the validations. After validation succeeds, you set the private field and notify the changed property for the UI to be updated according to ViewModel's State.
Here goes some code as example.
Update to address some comments
That's correct. The important stuff of your screen is the State, not the combobox (which is not known by the viewModel). I can't see how my example fails this.
Who said it is no ok to do that? Do you see any problem in having a viewModel loading localized messages at runtime, for example? If it's OK or not will depend on your application needs.
What I tried to say is that graphics and visual stuff are placed ONLY in the View, and the state and behaviour are placed in the ViewModel. So, therefore, you GUIs are represented partly by the View, and partly by the ViewModel. That's why I said that in the example, the viewModel is your user interface, since i'm not considering details such as Combobox or GridView or whatever; I'm only interested in the behaviour of the screen, and this behavior should be entirely implemented in your viewModel, if you chose to follow MVVM pattern.
But, you don't need to believe me, please just read Presentation Model (another name for the same pattern) article and the other source mentioned below.
What I meant is that there might be a requirement like: "When user changes the value of the state, there must be performed a validation on it, and the view must update this value only if validation succeeds."
Because of that, you want to implement some behavior on you GUI: the user changes a combobox' value, and the validation occurs; if validation fails, combobox's value stays the same; otherwise a new value is set in the combobox.
The above statement is implemented by my example, following ModelView-ViewModel design pattern. Actually, in the code example I put ValidateState in the ViewModel, but the idea is that the viewModel triggers the validation logic that should be implemented somewhere else; the code is to serve just as an example to aid you in your development scenario. But, if anything above seems like bad practice after all to you, this is just a suggestion anyways :)
I agree and I personally don't see the code smell here.
Let me answer that by quoting Martin Fowler in his Presentation Model article:
...And by quoting MVVM article from Msdn:
About the code-behind file: this is just the C# part of your XAML. All code you put there should address only presentation concerns; ideally, behavior and state of your GUI should be implemented in the ViewModel classes. At least this is what is described as the pattern, by the sources below. I suggest you to fully read and understand below articles.
Sources:
https://martinfowler.com/eaaDev/PresentationModel.html
https://msdn.microsoft.com/en-us/library/hh848246.aspx