Using “vanilla” WPF (no MVVM framework like Prism).
Let me say up front that I absolutely advocate coding against abstractions/interfaces vs. implementations whenever possible.
In WPF, when you do your bindings in the view, you are really not coding your bindings against the viewmodel interface. You are really binding against an implementation of the viewmodel/datacontext. I think you could even argue that you are binding against a blank canvas, since the view doesn’t really have any knowledge of what it will bind to at runtime.
So is a view model interface that includes every property that the view will bind to a useless abstraction? Should view model interfaces be leaner, only containing methods needed to change state (or handle commands, etc.).
I hope that question makes sense. 🙂
IMHO, the ViewModel is a Model for the View. 90% of the time, they will likely be 1 to 1… the useful part is moving the logic back into something more testable than XAML. Together, they compose the UI, but the UI behavior is separated from the UI presentation.
Personally, I do not make use of ViewModel interfaces. Between the Command Pattern and the loose binding that WPF and Silverlight use, I don’t feel that abstraction would be useful.
I might use ViewModel interfaces in a system where the behavior and View state differed widely based on some business criteria. E.g. if your View was doing driver’s license field editing and the fields required varied from state to state, you could make a case for a single, complex view bound to an IStateDriversLicenseViewModel interface. The correct one could be dependency injected based on the state you are working on and could expose properties like IsOrganDonorSectionVisible, to allow the view to reflect the correct changes. However, in this case I suspect a view composed of user controls would lead to fewer problems and less complexity in maintenance.