In recent projects I came into, I found out that the first M in the M-V-VM pattern is usually  flying away. The user which develops the view using this pattern, usually will start with the ViewModel, containing all the properties and the commands needed. After that, usually the View comes in place and is used in order to psent the data. But where did the model run away?

The  thin-client thinking led to service-oriented clients. The good-old MVVM pattern talks about this, basically:

(thanks to reed compsy (http://reedcopsey.com/blog) for this diagram).

Usually, clients do not live by themselves. They work against the server, which, by himself contains the entities psentations. Moreover, Pure Model should not hold the operations on the model as specified in the diagram above. It should be as clean as possible, implementing only notifyable / data error patterns.

Usually we find view models acquiring the services needed for them, registering to their relevant events, and receiving notifications about the changes made to the models.

It looks more like this:

The benefits of this service-driven MVVM (or S-V-VM, which stands for Service-View-ViewModel) are as followed:

• Easy to understand, Clear.
• The core operations, which can take a large amount of time, are pformed on the backend.
• The model does not update without having the server up, running and available to update the database or I/O. Moreover, if the server fails to update all the request changes, it only sends notifications about the model changes that have been done.
• Supports multiple clients, whereas each client can update the viewmodel independently, but only updating the service causes all the clients' viewmodels to receive update notification which causing the relevant Views to update.
• Supports client startup, on which a Sync() is performed causing the ViewModel to receive all the latest model changes.

I'd try to add a client-server sample using WPF/WCF with this pattern ASAP.