Menu
button has a Command binding into ViewModel (it runs some Save method in ViewModel). Method Save can fail and throw an exception.
What is a best practice how to catch those exceptions? It would suffice to show a MessageBox but I do not want to do it in ViewModel (this is not the right way).
574
The view classes have no idea that the model classes exist, while the ViewModel and model are unaware of the view. In fact, the model is completely oblivious to the fact that the ViewModel and view exist. This is a very loosely coupled design, which pays dividends in many ways, as you will soon see. Why WPF Developers Love MVVM
Through this interface, the view model must listen for commands it wants to handle. This seems to be a lot of baggage for the view model to deal with, and more importantly, this creates a dependency between the view model and WPF commands.
The command should be on the ViewModel. In MVVM, the ViewModel is the thing that should contain all of the logic that drives the view. The view is the simple class - just a collection of UI controls whose state is bound to properties on the ViewModel.
When you use the Model-View-ViewModel (MVVM) design pattern, a command is exposed on the ViewModel as a property that implements the ICommand interface. Controls on the View bind to these properties.
1 - I don't believe it's "not the right way".
Having an Exception raised in ViewModel is typically part of the ViewModel logic. Therefore, showing a MessageBox there wouldn't be "the bad way".
Keep in mind that the actual aim of MVVM is NOT to eliminate ALL code-behind, but is actually to clearly separate UI-logic and business-logic. An exception will happen when dealing with business objects -- you can handle it in the ViewModel
2 - Anyway if you want to stick with this approach (I'd qualify it as an extremist MVVM - heh -) you could:
Binding.ValidationRules ? if not, this article should be useful for you ) to ensure data entered won't create an Exception
Exception happens, ie. try-catch, and if you ever happen to enter in catch, you'll return a specific Error value which will be treated by UI as an error (you could for example use a Trigger to color the field in red if this specific error value has been returned)Anyway again I think that there are a lot of people who want to apply an "extremist MVVM" by eliminating all possible code-behind and introducing complex patterns (Attached Behaviors for example...) just to follow a requirement which is actually nonsense in my opinion. I won't say I'm absolutely right, but I prefer to see MVVM as a pattern which will simplify my way of coding than a pattern which will introduce me so much pain for basic things (for example I've seen people implementing AttachedBehaviors for a simple DoubleClick action. I personally add an EventHandler firing the DoubleClick command to my MVVM when the DoubleClick event is fired. 1 line of code against a 100-lines class + XAML code for the other approach, choose your side. I believe that a simple problem should have a simple solution)
Cheers!
170
why you think its not the right way to show a messagebox? cause of unit test for the viewmodel? if thats your problem just write a IMessageBoxService which you use in your vm.
this post shows how to create a dialog service. so you have to improve it a little bit to get the messageboxservice you want.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
