title: Proper validation with MVVM
body: <p><em>Warning: Very long and detailed post.</em></p>
  
  <p>Okay, validation in WPF when using MVVM. I’ve read many things now, looked at many SO questions, and tried <em>many</em> approaches, but everything feels somewhat hacky at some point and I’m really not sure how to do it <em>the right way</em>™.</p>
  
  <p>Ideally, I want to have all validation happen in the view model using <a href="http://msdn.microsoft.com/en-us/library/system.componentmodel.idataerrorinfo.aspx" rel="noreferrer"><code>IDataErrorInfo</code></a>; so that’s what I did. There are however different aspects that make this solution be not a complete solution for the whole validation topic.</p>
  
  <h3>The situation</h3>
  
  <p>Let’s take the following simple form. As you can see, it’s nothing fancy. We just have a two textboxes which bind to a <code>string</code> and <code>int</code> property in the view model each. Furthermore we have a button that is bound to an <code>ICommand</code>.</p>
  
  <p><img src="https://i.stack.imgur.com/UqvT1.png" alt="Simple form with only a string and integer input"></p>
  
  <p>So for the validation we now have a two choices:</p>
  
  <ol>
  <li>We can run the validation automatically whenever the value of a text box changes. As such the user gets an instant response when he entered something invalid.
  
  <ul>
  <li>We can take this one step further to disable the button when there are any errors.</li>
  </ul></li>
  <li>Or we can run the validation only explicitly when the button is pressed, then showing all errors if applicable. Obviously we can’t disable the button on errors here.</li>
  </ol>
  
  <p>Ideally, I want to implement choice 1. For normal data bindings with activated <a href="http://msdn.microsoft.com/en-us/library/system.windows.data.binding.validatesondataerrors.aspx" rel="noreferrer"><code>ValidatesOnDataErrors</code></a> this is default behavior. So when the text changes, the binding updates the source and triggers the <code>IDataErrorInfo</code> validation for that property; errors are reported back the view. So far so good.</p>
  
  <h3>Validation status in the view model</h3>
  
  <p>The interesting bit is to let the view model, or the button in this case, know if there are any errors. The way <code>IDataErrorInfo</code> works, it is mainly there to report errors back to the view. So the view can easily see if there are any errors, display them and even show annotations using <a href="http://msdn.microsoft.com/en-us/library/system.windows.controls.validation.errors.aspx" rel="noreferrer"><code>Validation.Errors</code></a>. Furthermore, validation always happens looking at a single property.</p>
  
  <p>So having the view model know when there are any errors, or if the validation succeeded, is tricky. A common solution is to simply trigger the <code>IDataErrorInfo</code> validation for all properties in the view model itself. This is often done using a separate <code>IsValid</code> property. The benefit is that this can also be easily used for disabling the command. The drawback is that this might run the validation on all properties a bit too often, but most validations should be simply enough to not hurt the performance. Another solution would be to remember which properties produced errors using the validation and only check those, but that seems a bit overcomplicated and unnecessary for most times.</p>
  
  <p>The bottom line is that this could work fine. <code>IDataErrorInfo</code> provides the validation for all properties, and we can simply use that interface in the view model itself to run the validation there too for the whole object. Introducing the problem:</p>
  
  <h3>Binding exceptions</h3>
  
  <p>The view model uses actual types for its properties. So in our example, the integer property is an actual <code>int</code>. The text box used in the view however natively only supports <em>text</em>. So when binding to the <code>int</code> in the view model, the data binding engine will automatically perform type conversions—or at least it will try. If you can enter text in a text box meant for numbers, the chances are high that there won’t always be valid numbers inside: So the data binding engine will fail to convert and throw a <code>FormatException</code>.</p>
  
  <p><img src="https://i.stack.imgur.com/NK46t.png" alt="Data binding engine throws an exception and that’s displayed in the view"></p>
  
  <p>On the view side, we can easily see that. Exceptions from the binding engine are automatically caught by WPF and are displayed as errors—there isn’t even a need to enable <a href="http://msdn.microsoft.com/en-us/library/system.windows.data.binding.validatesonexceptions.aspx" rel="noreferrer"><code>Binding.ValidatesOnExceptions</code></a> which would be required for exceptions thrown in the setter. The error messages do have a generic text though, so that could be a problem. I have solved this for myself by using a <a href="http://msdn.microsoft.com/en-us/library/system.windows.data.binding.updatesourceexceptionfilter.aspx" rel="noreferrer"><code>Binding.UpdateSourceExceptionFilter</code></a> handler, inspecting the exception being thrown and looking at the source property and then generating a less generic error message instead. All that capsulated away into my own Binding markup extension, so I can have all the defaults I need.</p>
  
  <p>So the view is fine. The user makes an error, sees some error feedback and can correct it. The view model however <em>is lost</em>. As the binding engine threw the exception, the source was never updated. So the view model is still on the old value, which isn’t what’s being displayed to the user, and the <code>IDataErrorInfo</code> validation obviously doesn’t apply.</p>
  
  <p>What’s worse, there is no good way for the view model to know this. At least, I haven’t found a good solution for this yet. What would be possible is to have the view report back to the view model that there was an error. This could be done by data binding the <a href="http://msdn.microsoft.com/en-us/library/system.windows.controls.validation.haserror.aspx" rel="noreferrer"><code>Validation.HasError</code></a> property back to the view model (which isn’t possible directly), so the view model could check the view’s state first.</p>
  
  <p>Another option would be to relay the exception handled in <code>Binding.UpdateSourceExceptionFilter</code> to the view model, so it would be notified of it as well. The view model could even provide some interface for the binding to report these things, allowing for custom error messages instead of generic per-type ones. But that would create a stronger coupling from the view to the view model, which I generally want to avoid.</p>
  
  <p>Another “solution” would be to get rid of all typed properties, use plain <code>string</code> properties and do the conversion in the view model instead. This obviously would move all validation to the view model, but also mean an incredible amount of duplication of things the data binding engine usually takes care of. Furthermore it would change the semantics of the view model. For me, a view is built for the view model and not the reverse—of course the design of the view model depends on what we imagine the view to do, but there’s still general freedom how the view does that. So the view model defines an <code>int</code> property because there is a number; the view can now use a text box (allowing all these problems), or use something that natively works with numbers. So no, changing the types of the properties to <code>string</code> is not an option for me.</p>
  
  <p>In the end, this is a problem of the view. The view (and its data binding engine) is responsible for giving the view model proper values to work with. But in this case, there seems to be no good way to tell the view model that it should invalidate the old property value.</p>
  
  <h3>BindingGroups</h3>
  
  <p><a href="http://msdn.microsoft.com/en-us/library/system.windows.data.bindinggroup.aspx" rel="noreferrer">Binding groups</a> are one way I tried to tackle this. Binding groups have the ability to group all validations, including <code>IDataErrorInfo</code> and thrown exceptions. If available to the view model, they even have a mean to check the validation status for <em>all</em> of those validation sources, for example using <a href="http://msdn.microsoft.com/en-us/library/system.windows.data.bindinggroup.commitedit.aspx" rel="noreferrer"><code>CommitEdit</code></a>.</p>
  
  <p>By default, binding groups implement choice 2 from above. They make the bindings update explicitly, essentially adding an additional <em>uncommitted</em> state. So when clicking the button, the command can <em>commit</em> those changes, trigger the source updates and all validations and get a single result if it succeeded. So the command’s action could be this:</p>
  
  <pre><code> if (bindingGroup.CommitEdit())
       SaveEverything();
  </code></pre>
  
  <p><code>CommitEdit</code> will only return true if <em>all</em> validations succeeded. It will take <code>IDataErrorInfo</code> into account and also check binding exceptions. This seems to be a perfect solution for choice 2. The only thing that is a bit of a hassle is managing the binding group with the bindings, but I’ve built myself something that mostly takes care of this (<a href="https://stackoverflow.com/q/17596719/216074">related</a>).</p>
  
  <p>If a binding group is present for a binding, the binding will default to an explicit <a href="http://msdn.microsoft.com/en-us/library/system.windows.data.updatesourcetrigger.aspx" rel="noreferrer"><code>UpdateSourceTrigger</code></a>. To implement choice 1 from above using binding groups, we basically have to change the trigger. As I have a custom binding extension anyway, this is rather simple, I just set it to <code>LostFocus</code> for all.</p>
  
  <p>So now, the bindings will still update whenever a text field changes. If the source could be updated (binding engine throws no exception) then <code>IDataErrorInfo</code> will run as usual. If it couldn’t be updated the view is still able to see it. And if we click our button, the underlying command can call <code>CommitEdit</code> (although nothing needs to be committed) and get the total validation result to see if it can continue.</p>
  
  <p>We might not be able to disable the button easily this way. At least not from the view model. Checking the validation over and over is not really a good idea just to update the command status, and the view model isn’t notified when a binding engine exception is thrown anyway (which should disable the button then)—or when it goes away to enable the button again. We could still add a trigger to disable the button in the view using the <a href="http://msdn.microsoft.com/en-us/library/system.windows.controls.validation.haserror.aspx" rel="noreferrer"><code>Validation.HasError</code></a> so it’s not impossible.</p>
  
  <h3>Solution?</h3>
  
  <p>So overall, this seems to be the perfect solution. What is my problem with it though? To be honest, I’m not entirely sure. Binding groups are a complex thing that seem to be usually used in smaller groups, possibly having multiple binding groups in a single view. By using one big binding group for the whole view just to ensure my validation, it feels as if I’m abusing it. And I just keep thinking, that there must be a better way to solve this whole situation, because surely I can’t be the only one having these problems. And so far I haven’t really seen many people use binding groups for validation with MVVM at all, so it just feels odd.</p>
  
  <p>So, what exactly is the proper way to do validation in WPF with MVVM while being able to check for binding engine exceptions?</p>
  
  <hr>
  
  <h2>My solution (/hack)</h2>
  
  <p>First of all, thanks for your input! As I have written above, I’m using <code>IDataErrorInfo</code> already to do my data validation and I personally believe it’s the most comfortable utility to do the validation job. I’m using utilities similar to what Sheridan suggested in his answer below, so maintaining works fine too.</p>
  
  <p>In the end, my problem boiled down to the binding exception issue, where the view model just wouldn’t know about when it happened. While I could handle this with binding groups as detailed above, I still decided against it, as I just didn’t feel all that comfortable with it. So what did I do instead?</p>
  
  <p>As I mentioned above, I detect binding exceptions on the view-side by listening to a binding’s <code>UpdateSourceExceptionFilter</code>. In there, I can get a reference to the view model from the binding expression’s <a href="http://msdn.microsoft.com/en-us/library/system.windows.data.bindingexpression.dataitem.aspx" rel="noreferrer"><code>DataItem</code></a>. I then have an interface <code>IReceivesBindingErrorInformation</code> which registers the view model as a possible receiver for information about binding errors. I then use that to pass the binding path and the exception to the view model:</p>
  
  <pre><code>object OnUpdateSourceExceptionFilter(object bindExpression, Exception exception)
  {
      BindingExpression expr = (bindExpression as BindingExpression);
      if (expr.DataItem is IReceivesBindingErrorInformation)
      {
          ((IReceivesBindingErrorInformation)expr.DataItem).ReceiveBindingErrorInformation(expr.ParentBinding.Path.Path, exception);
      }
  
      // check for FormatException and produce a nicer error
      // ...
   }
  </code></pre>
  
  <p>In the view model I then remember whenever I am notified about a path’s binding expression:</p>
  
  <pre><code>HashSet&lt;string&gt; bindingErrors = new HashSet&lt;string&gt;();
  void IReceivesBindingErrorInformation.ReceiveBindingErrorInformation(string path, Exception exception)
  {
      bindingErrors.Add(path);
  }
  </code></pre>
  
  <p>And whenever the <code>IDataErrorInfo</code> revalidates a property, I know that the binding worked, and I can clear the property from the hash set.</p>
  
  <p>In the view model I then can check if the hash set contains any items and abort any action that requires the data to be validated completely. It might not be the nicest solution due to the coupling from the view to the view model, but using that interface it’s at least somewhat less a problem.</p>