Hello,
I've been doing MVVM for a couple of years now, and have been working on a large project that was already fairly well developed before I joined the team. I have been following the way the pattern was implemented, and learnt MVVM from that.
I've been reading around a bit, and am not sure if the way we're doing MVVM is the same as other people, nor if we are doing it the "right" way (I know, there's no right and wrong, but there are better and worse ways).
Our take on it is that the view is as dumb as can be, and knows nothing about the viewmodel. Actually, that's not strictly true, we use an IOC container (Ninject as it happens, but that's probably irrelevant), and bind the view's DataContext like this...
DataContext="{Binding Source={StaticResource Locator}, Path=ComponentsListViewModel}"The viewmodel contains injected references to WCF services, and makes calls to those services to get the data, which is used to populate properties on the viewmodel. Those properties are bound to controls on the view. When properties change, or when commands are fired, the viewmodel makes service calls to send the modified data back.
Any particular view may make several service calls, and have any number of properties, some collections, some individual entities. If so, where is the model? People talk about the model as if it were a separate class, containing the data used by the viewmodel, but in our case, the data is pulled in from the services by the viewmodel, and is stored there. I don't see anything that can be called a model.
Are we doing this wrongly, or is this a valid way to do it? I would be interested to hear what other people are doing.
Thanks
FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers. Download from the Visual Studio Gallery.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies athttp://dotnetwhatnot.pixata.co.uk/