Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In order to make a View entirely independent of the Model you would need to reproduce types that in many cases are identical to the Model types in your ViewModel.</p> <p><strong>Example</strong></p> <p>A Model contains a <code>Person</code> type that have <code>FirstName</code> and <code>LastName</code> properties. The visual design calls for a "List of people" so there is a View containing a ListBox that has a data template binding to property paths of <code>FirstName</code> and <code>LastName</code>. The <code>ItemsSource</code> binds to a property of ViewModel that exposes a set instances of types that have a <code>FirstName</code> and <code>LastName</code> property. </p> <p>So here is the question, <strong>should there be a "ViewModel version" of the Model <code>Person</code> type or should the ViewModel simply re-use the existing <code>Person</code> type from the Model?</strong> </p> <p>In either case its quite possible that you would want the properties to be observable.</p> <p><strong>To consider</strong></p> <p>What are the objectives behind MVVM? Quite often we like to present nice long lists of why a pattern exists but in this case there are really only 2.</p> <ul> <li>Separate visual design (<strong>note</strong>: not design) from code.</li> <li>Maximise the testable surface of the overall application.</li> </ul> <p>Exposing Model types on the ViewModel doesn't form an obstacle to either of the above objectives. In fact it aids testability since the number of types and members that need testing is reduced.</p> <p>In my opinion I don't see that implementing INotifyPropertyChanged <em>implies</em> binding to visuals. There may be other reasons why some service may want to observe changes in properties of a model object.</p> <p>The key principle in the separation of Model from View is hiding of any specifics about the how the View presents the Model from the Model itself. Adding a <code>ForenameBackColor</code> property to the Model would be probably be bad. This is where the ViewModel comes in.</p> <p><strong>Bottom Line</strong></p> <p>Requiring the Model to expose observable properties is not breach of MVVM, its a simple and general requirement that does not require the Model to have any specific knowledge of any View or indeed that there are any "visuals" involved at all.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload