title: Should the MVVM ViewModel perform type conversion/validation?
body: <p>We're just getting into MVVM in WPF.</p>
  
  <p>We have implemented our ViewModels with 'strongly typed' properties (int, double? etc.) that we bind to in the view.</p>
  
  <p>Type conversion works OK, mostly, and so entering data is simple enough. But we run into problems with validation.</p>
  
  <p>If, say, a non-numeric value is entered in a text box bound to a numeric property, the conversion fails, the property is never set, and we never get a chance to provide proper feedback to the user. Worse, the property retains its current value, leading to a mismatch between what's displayed in the view and what's actually in the ViewModel.</p>
  
  <p>All this can be handled with value converters, I know. But I have seen several opinions to the effect that conversion should not be the view's responsibility at all. What is entered in the view are strings, and the conversion, validation etc. should be the ViewModel's responsibility (so the argument goes).</p>
  
  <p>If so, we should rewrite most of the properties on our ViewModels to string, and provide error information through the IErrorInfo interface, for example. It would surely make for simpler, leaner XAML in the view. On the other hand, conversion, validation etc. will be less declarative, explicit and flexible, from the point of view of the View designer.</p>
  
  <p>It seems to us these two approaches are fundamentally different, so before we decide, we'd like some informed SO opinions on the matter.</p>
  
  <p>So: should ViewModels expose a simplified, 'text-based' interface to the view and handle conversion internally? Or should ViewModel properties expose the actual data types, leaving such chores to the view to handle?</p>
  
  <p><strong>Update:</strong></p>
  
  <p>Hard to pick a winner here, but I finally landed on one of you who concludes more or less like myself.</p>
  
  <p>Specifically, we have decided to keep the ViewModel properties typed. The main reason for this is the flexibility it affords us in the design of the view, and the power of explicit, declarative conversion/formatting in XAML.</p>
  
  <p>I noticed an assumption with you who will disagree with us in this, that the design of the view is fixed and ready. Hence, no decisions about conversion, formatting etc. need be made in the view. But ours is an agile process, and we haven't got all the nitty gritty detail of the UI figured out on beforehand.</p>
  
  <p>In fact, leaving the details of the UI to be worked out along the way leaves room for creativity and besides, in my opinion, even a meticulously worked out design will always end up morphing throughout the implementation process.</p>
  
  <p>The point of all this is that whereas business rules enforcement certainly belongs in the ViewModel, it seems to us that simple conversion and formatting is a view-thing. It may sound like heresy, but I don't actually think type conversion in the view needs unit testing at all (so long av we unit test the actual type converters).</p>
  
  <p>All in all a great discussion, folks, with well formulated, informed opinions. Thanks.</p>