If you are creating literally the same screen in Silverlight and WPF is it appropriate to share the same ViewModel or is that just plain wrong.
I know the VM is UI specific and therefore will likely need to do different things on SL and WPF but couldn't I still share the commonalilty in a base VM for that screen?
Is inheritance in VMs a road that should be avoided?
Thanks for any and all thoughts.
I am of the opinion that the viewmodel should be:
What this means, is that a viewmodel should focus on the user experience and navigation structure first and foremost. As a result, a viewmodel for a PC screen size will often work for other similar screen sizes across technologies. But it won't work between PC and phone screen sizes, because the user workflow isn't the same.
It also means that you should avoid having your viewmodel use any UI-specific types. No properties that return a Brush or other XAML type that might vary from WPF to SL to WinRT. That's what value converters are for, and the viewmodel should stick with native property types.
Where you can end up stuck with technology dependent code is when using things like the WP7 app bar. But even there, I am tending to use small bits of code-behind to glue nasty platform controls to the viewmodel, rather than contaminating the viewmodel with platform-specific types.
Thanks for the reply and insght Rocky.
I'm still left wondering a little though...did you give a thumbs up or a thumbs down to sharing a single VM (or a base VM) among Silverlight and WPF (I'm thinking simple Windows and PC browser now).
I suppose I gather from your answer that I really cannot think of a single user experience (a screen that looks, smells, acts the same) shared in two environments. Rather I need to think about the whole applications - navigation and context. Which is a bit of a bummer as I suppose I had really kind of been thinking in terms of non-workflow type applications - i.e. where a container controls the navigation and most screens (not all of course) encapsulate their part of the puzzle completely.
As a major role of the VM is to shape the M for presentation we might introduce properties there that could equally be useful in both environments so I'd really want to avoid duplication. I can see too, though, how tying both together might result in 1. redundant VM properties in one environment 2. complexity of inheritance and base class polution 3. navigation confusion.
I suppose my real goal right now is to facilitate a migration from winforms to WPF and/or Silverlight. There is little doubt in my mind that the first serious migration choice (of the business and management) will be to WPF with Silverlight seen as a more web/asp.net(intranet) related change. And it is hard to argue - WPF is more closely aligned to what we can achieve in Winforms. But I worry about the furture and WinRT and the general consensus that those doing Silverlight now will have an earier migration time.
In the much delayed (for which I am very sorry) Using CSLA 4: WPF and Silverlight ebook, I reuse all viewmodel base classes and viewmodel classes between WPF and Silverlight.
I expect that when I create the WinRT ProjectTracker UI, that I'll reuse those same viewmodel types in WinRT too.
Thank you Rocky. I tested out some VM sharing between WPF and SL and it went quite well. Good to know that you don't think its a rocky road.
oops, I just noticed that this might not have been the best phraseology. I don't even know if it translates States-side but I meant a route fraught with problems basically. Obviously a Rocky road is a whole other more pleasant journey route 
'Rocky Road' is also an ice cream (a good one)
I knew what you meant ;)
mmmmm icecream! Funny thing is that in Ireland (where I live) icecream season pretty much ends when the summer season (note: I say season rather than weather!) ends but here in Helsinki (where I also live 
) I see folk eating icecream in the depths of winter when temperatures can drop to -35 °C.
Copyright (c) Marimer LLC