title: How have you combined the advantages of the direct View-to-Model approach and MVVM in your WPF projects?
body: <p>In our application we have many <strong>Model</strong> objects that have <strong>hundreds</strong> of properties.</p>
  
  <p>For every property on the <strong>model</strong>:</p>
  
  <pre><code>public string SubscriptionKind { get; set; }
  ...100x...
  </code></pre>
  
  <p>we had to make an INotifyPropertyChanged-enabled property on the <strong>ViewModel</strong>:</p>
  
  <pre><code>#region ViewModelProperty: SubscriptionKind
  private int _subscriptionKind;
  public int SubscriptionKind
  {
      get
      {
          return _subscriptionKind;
      }
  
      set
      {
          _subscriptionKind = value;
          OnPropertyChanged("SubscriptionKind");
      }
  }
  #endregion
  
  ...100x...
  </code></pre>
  
  <p>which meant that when our <strong>View</strong> sent the <strong>Save</strong> event, we had to remap all these values of the view model back into the model:</p>
  
  <pre><code>customer.SubscriptionKind = this.SubscriptionKind
  ...100x...
  </code></pre>
  
  <p>This became <strong>tedious</strong> and time-consuming as the models kept changing and we had to map all changes up into the ViewModels.</p>
  
  <p>After awhile we realized that it would be more straight-forward to just <strong>connect the DataContext of the View directly</strong> to the Model which enables us to bind the XAML elements directly to the Model object properties so that the save event would simply save the object without any mapping whatsoever.</p>
  
  <p>What we <strong>lost</strong> in this move is:</p>
  
  <ul>
  <li><p>the ability via <code>UpdateSourceTrigger=PropertyChanged</code> to do fine-grained <strong>validation</strong> and manipulation in the ViewModel Property Setters, which I really liked: this we don't have anymore since any change in XAML simple changes the dumb property on the Model</p></li>
  <li><p>the ability (in the future) to create <strong>mock views</strong> which test our viewmodel's UI logic in a novel way, e.g. "if property SubscriptionKind is set to "Yearly" then (1) change discount to 10%, (2) run "congratulations animation", and (3) make order button more prominent.</p></li>
  </ul>
  
  <p><strong>Both</strong> of these approaches have <strong>obvious advantages</strong>, e.g. the first way "View-direct-to-Model" approach especially when combined with <strong>LINQ-to-SQL</strong> is pragmatic and enables you to produce useful software fast, and as long as you use <code>{Binding...}</code> instead of <code>x:Name</code> you still have the ability to "hand off your views to a Blend Designer".</p>
  
  <p>On the other hand, although MVVM requires you to maintain tedious mapping of Model to ViewModel, it gives you powerful <strong>validation</strong> and <strong>testing</strong> advantages that the first approach doesn't have.</p>
  
  <p><strong>How have you been able to combine the advantages of these two approaches in your projects?</strong></p>