Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I have two main thoughts on this, but YMMV.</p> <p>Firstly I would move the implementation specific code from the VM into 'service' which is basically just a class that does the work. This may be for example a 'customerService' class which has the implementation of the save, delete, update methods, and the RelayCommand implementation will call the service to perform the action, and update any view properties as appropriate. </p> <p>An example would be that the RelayCommand may set the value of a "ShowProgressBar" property, which is bound to the visibility of a progress bar. It would then call the save function in the service, and when complete (this should be asynchronous btw) it should again update the "ShowProgressBar". In this way the ViewModel is controlling the state of the View independently of the core application logic.</p> <p>Secondly I would look into the base viewmodel you are using and try keep that as simple as possible, only adding components that are common to all your viewmodels. You can then create other base view models or interfaces as appropriate. For example you may decide that all your view models will expose a ShowProgressBar property which can be bound to a progress bar on your page, or you may decide to create a ProgressViewModelBase or IAllowProgress that you inherit/implement in pages that require progress bars.</p> <p>The View itself should have as little code as possible, you should aim for 0 code-behind (though there are things that can only be done in code-behind unfortunately).</p> <p>One thing I found to my detriment is that instantiation of complex viewmodels can be expensive in terms of performance, especially if you are registering relaycommands and event aggregator sources/listeners, so keeping the base viewmodel slim us very useful. This is especially important if you are using a ViewModelCollections to display lists of Model objects and where the ViewModel creation occurs on the UI thread (which is likely if the ViewModel is instantiated on the View Creation).</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