WPF - Is it a good idea to keep the ViewModel agnostic of WPF?

Question

In the subject really, I want to know people's experience of trying to keep all WPF concerns out of ViewModels in WPF.

Cheers

AWC

Answer 1

My personal guideline: Yes, if it's easily doable. I really like the separation of concerns of the View - ViewModel approach, but since I'm pretty sure that I'll never use my ViewModels without WPF, I won't make my code more complex or less readable just to avoid a WPF reference.

Answer 2

I've always found that one of the most useful things a ViewModel does for me is to marshall object access onto the Dispatcher thread, to save all those awkward errors about 'this object can only be accessed from the UI thread'. I would say that's in conflict with being WPF agnostic, so it's not a universal rule that you should strive to be agnostic. Of course it's not a great idea to have your ViewModel holding collections of eg. ListBoxItems or anything like that. Separation is nice but you have to make some concessions to the technology's needs.

Answer 3

AWC,

From my experience, it is the best pracice not to keep all WPF concerns out of ViewModel. I'm not talking about View - specific classes (listboxes, textBlocks, etc), but we should always keep in mind that managing access to the UI thread is a vital part of WPF and it should me maintained from within ViewModel. This is because the View is responsible only for providing a clear template for presenting data provided by VM. It is ViewModel which decides if data should be retrieved asynchronously and in which circumstances it should be bound - above implies use of Dispatcher which manages access to UI thread. So my answer is: don't forget that WPF is not only a View class.

I believe you wanted to ask if developers should not worry about View in VM classes. If I'm right, the answer is yes, they shouldn't worry. ViewModel is just a layer providing complete set of data/commands to an anonymous presenter (View) - it does not care neither what part of provided data will be used by bound Views nore how that data will be presented.

I hope my answer is helpful. Please feel free to ask if you have any further questions.

Answer 4

I think it is almost always possible, as long as you don't mind writing a bit more code. :)

Think of the things that you could somehow represent on the ViewModel side:

1. Controls - BAD idea, for innumerable reasons.
2. Brushes - Can easily be moved to converter outputs, static resources, and templates.
3. Enum values like Visibility, etc - again, converters are your friend here; bool to visibility, X to visibility, etc.
4. Event handlers - these become ICommands in the "new world"
5. The Dispatcher: This is the one thing I will occasionally "cheat" on, but I feel dirty everytime I do. :)

I don't know, maybe I'm just a purist, but if I see any "using System.Windows" or "using System.Windows.Controls" at the top of my view model, I know I've taken an easy way out of something that will likely come back and bite me in the ass later.

Answer 5

I disagree - isn't the point of the ViewModel to handle the impedance mismatch between the View and the Model? I don't think you need to keep the ViewModel 100% WPF-free - the VM is there to help you out.