Salut,
le mvvm est simplement un design pattern, il n'a rien d'obligatoire. Cela dit c'est assez epic une fois qu'on maîtrise plus ou moins la bête. Je crois qu'il n'existe pas vraiment de tuto complet à son sujet, j'ai moi même galéré quand je cherchais des infos. Il y a cependant un mec Laurent Bugnion (le développeur de MVVM Light) qui a fait une série de vidéo, il parle beaucoup de son framework mais sa éclair pas mal sur la façon de procédé, d'ailleurs une vois que tu sauras te débrouiller avec ce pattern je te conseil MVVM Light pour tes projets.
Faut aimer l'anglais par contre :
http://channel9.msdn.com/Blogs/kreekman/TechDays-2010-Understanding-the-Model-View-ViewModel-pattern
Je t'expliquerai bien le tout mais c'est vraiment long pour tout décrire. Mais je pense que la base est simple, tu as trois couches, le Model, qui représente tes données, la View qui représente ton interface, et le View Model qui fait le lien entre les deux. Le but étant de garder le tout séparé afin de faciliter l'écriture et la maintenance du code. La règle dit la vue ne doit connaitre que le View Model, le View Model ne doit connaitre que le Model. Donc Le Model ne connais rien d'autre et ne doit dépendre de rien d'autre que lui même. Le View Model lui est conçu pour exposer les propriétés à la vue, mais il ne la connais pas.
Avant de continuer un peu il faut aussi savoir que WPF est entièrement basé sur le principe MVVM, par exemple Blend de Microsoft a été entièrement codé sur ce principe. Ce que je veut dire c'est que le Binding et le DataContext sont utile que si tu utilise MVVM. Biensure je pense qu'on peut se débrouiller autrement en faisant les choses un peu plus a l'arrache mais sa perd de son charme.
Le DataContext représente en quelque sorte la source de donnée pour la vue. Donc techniquement ce sera toujours un View Model. En liant un DataContext a la vue, la vue a accès à toutes les propriétés du View Model grâce au Binding. Pour faire un exemple de raisonnement (sans code) :
Imaginons qu'on a un ViewModel avec une propriété nommé TextA, dans le constructeurs, tu l'initialise et tu lui donne comme valeur "Coucou". Notre View Model s'arrête la. Attention a bien mettre get;set; à la propriété. (le set n'est pas obligatoire dans notre exemple).
Notre vue est une simple fenêtre, je vais lui donné comme DataContext notre View Model. A partir de la, dans la mesure ou c'est ma fenêtre qui détient le DataContext, toutes les choses que je vais ajouté dans celle ci (qui seront donc "enfant" de la fenêtre) pourront accéder à mon View Model grâce au Binding.
Dans cette fenêtre on ajoute un TextBox, le TextBox à une propriété Text ou l'on peu écrire le texte a afficher. Mais nous on préfère qu'il affiche le "Coucou" de notre ViewModel. Donc on va écrire la chose suivante (oui j'ai dit pas de code mais bon ^^)
<TextBox Text="{Binding TextA}"/>
Comme on a pas donné de DataContext directement dans le TextBox il va chercher plus haut dans la hierarchie(les parents) un DataContext valide, et il trouvera celui de notre fenêtre qui est notre View Model, il va y chercher une propriété TextA qu'il va également trouvé et va donc afficher "Coucou".
Alors tu pourras dire tous ce bordel pour juste afficher du texte...Alors oui mais la puissance du binding n'est pas vraiment exploiter dans cette exemple. Je vais pas faire trop long encore, mais par exemple il y a l'interface INotifyPropertyChanged, qui permet de rafraîchir automatiquement la vue SI la donnée a changé, sans que tu n'es rien d'autre a faire. Et déjà ca c'est du luxe. INotifyPropertyChanged peut aussi servir a d'autre fin, il déclenche un event donc tu peux imaginer toute sorte de chose avec ca.
Je vais essayer de faire très court pour les Commands. Elles sont utiles car dans le MVVM, et comme je te disait au départ la vue connait le View Model, mais le View Model ne connait pas la Vue. Le View Model est conçu pour fonctionner même sans Vue (c'est ce qu'on appel View Model First). Il est donc logique qu'il faut trouver une solution lorsque l'utilisateur appuie sur un bouton. Car appuyer sur un bouton ca se passe dans la vue, mais l'action et dirigé par le View Model. Donc pour résoudre se problème on utlise des command, il en existe de plusieurs type, et chacun fait plus ou moins comme il le souhaite. Une command doit forcement intégrer l'interface ICommand, ce qui rend possible le binding avec la propriété Command des Buttons par exemple. En appuyant sur le bouton, la Command va donc déclencher une action dans le ViewModel sans que le View Model n'est eu besoin de connaitre la vue (et ca c'est la classe^^).
Je vais arrêter la, j'ai fait long et je sais même pas si c'est clair pour toi tous ca. Je te conseil fortement de persévérer dans ce domaine, WPF est vraiment une chouette techno même si un peu galère a comprendre. Et c'est regrettable qu'il n'y est pas plus de tuto clair la dessus.
Bon courage et n'hésite pas a poser tes questions.
). 
.
) 
