What is your experience with abandoning MVVM for U

Question

We built an large application based on Composite Application Library and MVVM using Infragistics controls.

In order to save time and make the application more straight-forward, we scrapped the MVVM requirement. We now have no Presenters or ViewModels and our Views have become simple UserControls which are created like this:

BaseEditor.cs:

using System.Windows.Controls;

namespace App
{
    public class BaseEditor : UserControl
    {
        public string Title { get; set; }
        public BaseEditor()
        {
            Title = "This was defined in the Base Editor.";
            Loaded += new System.Windows.RoutedEventHandler(BaseEditor_Loaded);
        }

        void BaseEditor_Loaded(object sender, System.Windows.RoutedEventArgs e)
        {
            StackPanel sp = new StackPanel();
            TextBlock tb = new TextBlock();
            tb.Text = Title;
            sp.Children.Add(tb);
            this.Content = sp;
        }
    }
}

CustomerEditor.cs:

namespace App
{
    public class CustomerEditor : BaseEditor
    {
        public CustomerEditor()
        {
            Title = "This was overwritten by the CustomerEditor.";
        }
    }
}

Window1.cs.xaml:

<Window x:Class="App.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:App"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <local:CustomerEditor/>
    </Grid>
</Window>

Apart from the testability issue and the fact that this "feels dirty" doing WPF like this, I have only experienced positive effects from this decision, e.g.:

• we can inherit our non-XAML UserControls from each other
• we use as much code-behind as we want which expedites development
• attaching the infragistic controls directly to our model class coming from the web service cleared up dozens of little binding problems we were having with binding Infragistics to ObservableCollections
• even in straight WPF, the lack of ObservableCollections make problems like not being able to create a simple Menu go away
• we are replacing the EventAggregator one-by-one with direct events using UserControls and code behind, which cleared up all kinds of problems with events

Has anyone else doing MVVM in WPF had similar experiences? Did you meet with any real problems in the long run?

Answer 1

A view model is good because it makes databinding easier. Databinding does not cover all that you need to do, so some code attached to the XAML is convenient.

In my experience a mix of view model and attaching to events seems to get the job done until a more pure approach can be worked out if required.

EDIT:

Attaching to events does not necessarily break the MVVM model if you use the event handler to forward the event to handler logic in your viewmodel or some other responsible object.

There are advantages to pure databinding in that you can more easily make different XAML skins which use the same viewmodel. One example is to have a debug skin which exposes some of the inner workings to help in development and a working skin which is the end product. The different XAML views can bind to the same viewmodel.