Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>1) Having your DTO class be updated by your external data service will not make it in to a viewmodel. Your DTO is part of your model or business object layer. Its job is to carry data between the presentation (view and viewmodel) and storage layers (database), and perform validation (if needed). Being updated by an external (non-view) service is well within the scope of its role. Your comment about one VM per window or usercontrol isn't wrong - VMs are assigned on a per view, not per control, basis (though it is possible to reuse the same VM class for multiple views). You should have the instance of the DTO that the view binds against on the VM. That's the VM's job - to organize, manage, and present to the view the required parts of the model.</p> <p>To have the DTO be aware of where the update originated from, as you mentioned in the question, you could add a flag to indicate whether it comes from the view or service and set as needed. Alternatively, you could make the service update the DTO through a public method, and have the view bind directly to the properties. Depending on your design, this option might be considerably less feasible than setting a flag.</p> <p>2) <a href="http://msdn.microsoft.com/en-us/library/system.componentmodel.ieditableobject.aspx" rel="nofollow"><code>IEditableObject</code></a>, as mentioned in the other answer, is a good choice. Having backups of both the service and view data on your DTO is unnecessary, and effectively triples the size of your object (assuming it's a thin wrapper, which it ought to be if it's a DTO). If you <strong><em>really</em></strong> need the ability to revert to either version of the data - say, because you give the user the option to pick which version to use when reverting - keep the extra data around on your VM instead of on the model. I can't think of a reason you'd need the option that doesn't involve some kind of presentation or user interaction decisions. Data driven reverting should be designed to always be deterministic.</p> <p>3) Again, <a href="http://msdn.microsoft.com/en-us/library/system.componentmodel.ieditableobject.aspx" rel="nofollow"><code>IEditableObject</code></a>. The view should not be notifying the viewmodel; it should be ignorant of the VM (not have any references). This will loosen the coupling between the two layers and increase the flexibility of your application. I typically achieve this by having a controller class dedicated solely to handling views. When it opens a view, it creates a new VM instance and points the view's <code>DataContext</code> at it.</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