Wpf – Why are events and commands in MVVM so unsupported by WPF / Visual Studio

commandeventsmvvmwpf

When creating an WPF application with the MVVM pattern, it seems I have to gather the necessary tools myself to even begin the most rudimentary event handling, e.g.

AttachedBehaviors I get from here
DelegateCommands I get from here

Now I'm looking for some way to handle the ItemSelected event in a ComboBox and am getting suggestions of tricks and workarounds to do this (using a XAML trigger or have other elements bound to the selected item, etc.). Ok, I can go down this road, but it seems to be reinventing the wheel. It would be nice to just have an ItemSelected command that I can handle in my ViewModel.

Am I missing some set of standard tools or is everyone doing MVVM with WPF basically building and putting together their own collection of tools just so they can do the simplest plumbing tasks with events and commands, things that take only a couple lines in code-behind with a Click="eventHandler"?

Best Answer

You're right about the complexity of commands. I try to follow the M-V-VM pattern as close as possible, but I can't justify sophisticated workarounds just to handle a simple user event.

In my opinion, it's OK to handle a user event in the View if that greatly simplifies your code. If you do handle a user event in the View, your View's code-behind should immediately call a method on the ViewModel. This way, you are still keeping your logic in the ViewModel… you just have a little plumbing code (event handler) in the View. I know the M-V-VM purists think there should be no code in the View's code-behind, but sometimes it just makes more sense to allow some simple boilerplate code like an event handler. Remember, others may have to read/modify your code in the future and it is much easier to understand an event handler than a DelegateCommand.

Related Solutions

C# – How should the ViewModel close the form

I was inspired by Thejuan's answer to write a simpler attached property. No styles, no triggers; instead, you can just do this:

<Window ...
        xmlns:xc="clr-namespace:ExCastle.Wpf"
        xc:DialogCloser.DialogResult="{Binding DialogResult}">

This is almost as clean as if the WPF team had gotten it right and made DialogResult a dependency property in the first place. Just put a bool? DialogResult property on your ViewModel and implement INotifyPropertyChanged, and voilà, your ViewModel can close the Window (and set its DialogResult) just by setting a property. MVVM as it should be.

Here's the code for DialogCloser:

using System.Windows;

namespace ExCastle.Wpf
{
    public static class DialogCloser
    {
        public static readonly DependencyProperty DialogResultProperty =
            DependencyProperty.RegisterAttached(
                "DialogResult",
                typeof(bool?),
                typeof(DialogCloser),
                new PropertyMetadata(DialogResultChanged));

        private static void DialogResultChanged(
            DependencyObject d,
            DependencyPropertyChangedEventArgs e)
        {
            var window = d as Window;
            if (window != null)
                window.DialogResult = e.NewValue as bool?;
        }
        public static void SetDialogResult(Window target, bool? value)
        {
            target.SetValue(DialogResultProperty, value);
        }
    }
}

I've also posted this on my blog.

.net – In WPF, what are the differences between the x:Name and Name attributes

There really is only one name in XAML, the x:Name. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name by using the RuntimeNamePropertyAttribute on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.

The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement introduces a Name property.

In general, a class does not need to store the name for x:Name to be useable. All x:Name means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.

So, why are there two ways to do the same thing? The simple answer is because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together by marking the Name property as an alias of x:Name.

In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.

Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.

See also AutomationProperties.Name VS x:Name, AutomationProperties.Name is used by accessibility tools and some testing tools.

Best Answer

Related Solutions

C# – How should the ViewModel close the form

.net – In WPF, what are the differences between the x:Name and Name attributes

Related Topic