Ich habe ein DataGrid mit einer Liste von Dateien, die zu einem bestimmten Vorgang gehören. Wenn der Benutzer nun einen Doppelklick auf die Datei macht, dann soll sich das Verknüpfte Programm öffnen.

Wie würde man es MVVM-konform implementieren? Wäre das eine Funktion, die man im Codebehind der View unterbringt oder eher in der Model-Schicht?

Vielen Dank für die Beteilung an dieser Auskunftssuche ;-)

Welches MVVM Framework setzte Du ein?
Über die Blend Interactivity Bibliothek kannst Du Events auf Commands abbilden und auf Dein ViewModel mappen. Je nach Framework werden die Commands angeboten.
Das sieht dann etwas so aus:

<ListBox Name="list">
  <i:Interaction.Triggers>
    <i:EventTrigger EventName="MouseDoubleClick">
      <Command:EventToCommand
           Command="{Binding Path=DataContext.DoSomethingCommand,ElementName=list}"
           CommandParameter="{Binding EventArgs.OriginalSource.DataContext, RelativeSource={RelativeSource Self}}"/>
    </i:EventTrigger>
  </i:Interaction.Triggers>
</ListBox>

@judgy Falls Du eine Quelle hast, die
a) MVVM als >Pattern< beschreibt
b) erklärt, dass/warum Commands wesentl. Bestandteil des Patterns sind (nicht nur eine gängige Variante seiner Implementierung)
c) erklärt, warum ein Aufruf des VM aus dem CodeBehind eine SoC-Verletzung darstellt
wäre ich sehr an einem Link interessiert. Einer, der nur a) erfüllt, wäre aber auch schon nicht schlecht. Ich kenne da eigentlich auch nur http://martinfowler.com/eaaDev/PresentationModel.html aus der Zeit, als MVVM noch PresentionModel hieß. Die meisten MVVM-Artikel reden immer gleich über die Implementierung. – Matthias Hlawatsch vor 4h

@Matthias: Ich antworte hier einmal ausführlich.
Ich habe vor 3 Jahren einmal einen Vortrag zu MVVM in der Berliner UG gehalten. (Die Powerpoint Folien sollte man starten, da sie viele Animationen enthalten). Heute würde ich den Vortrag ein wenig anders aufbauen, da ich denke, dass beim MVVM Pattern ein Controler fehlt und das Pattern MVVM-C heissen müsste.

Es ist wahr, dass es keine guten Artikel zum Thema MVVM gibt.
Mittlerweile glaube ich, dass es auch daran liegt, dass dieses Pattern nicht zu Ende gedacht und daher auch nicht vernünftig definiert wurde.

Die Gretchen-Frage dieses Pattern liegt in der Frage, wo die Logik liegt, die auf das Repository bzw auf den (WCF) Service zugreift: Im Model oder im ViewModel?
Daher gibt es auch so viele unbefriedigende Erklärungen und Beispiele.
Meine Antwort hierzu: Weder noch.
Desweiteren wird leider immer wieder vermischt, wer mit wem kommuniziert. Dabei wird das Model häufig direkt über das ViewModel an die View gekoppelt.

Gehen wir logisch vor:
Unser Ausgangslage ist SoC - die Belange sollen von einander getrennt werden. Das hat zur Folge:

View <- ViewModel <-> Model

Das ViewModel ist ein Abbild der View
Und das Model wird auf das ViewModel projiziert, bzw. injiziert.
Ins ViewModel kommen dann neben den Eigenschaften des injizierten Models, noch Funktionalitäten über Commands hinzu.
Das ViewModel ist dadurch definiert, das es das Prinzip des Bindings unterstützt, also vom INotifyPropertyChanged ableitet.

Übersichtlicher wird es durch

View <- ViewModel <-> ServiceAgent/Controler <-> Model

Zur Initialisierung des ViewModels wird über den Controler das Model injiziert.
Methoden, die über Comdands aufgerufen werden, führen erneut über den Controler zur Aktualisierung des Models. Das Model könnte z.B. auch der Proxy des WCF Service sen.

Wenn aber das ViewModel das Abbild der View ist, so haben wir es nicht nur mit einem ViewModel zu tun. Wir müssen es unterscheiden:

• PageViewModel
  Auf einer Seite sind nicht nur reine Daten abgebildet, sondern werden auch unterschiedliche Strukturen zusammengeführt. Desweiteren werden Operationen wie CRUD oder Navigation dort untergebracht. Man könnte es auch so formulieren, dass es auf einer Seite unterschiedliche Controls gibt, die je für ein DataViewModel stehen.
  
• DataViewModel
  Ein DataViewModel ist ein Abbild eines Models, wie es oben beschrieben wurde.
  
• ResourceViewModel
  Lokalisierte Texte werden über Ressourcen in die View eingebunden. Wenn wir unser Pattern korrekt anwenden, so müssten wir hierfür eine RessourceViewModel einführen, das je nach Sprache unsere View füllt.
  

Damit haben wir nun folgendes Bild

-  
     <- PageViewModel
View <- DataViewModel       <-> ServiceAgent/Controler <-> Model
     <- RessourceViewModel

Soweit, ich bin jetzt noch nicht auf Deine Fragen eingegangen.
Warum gehören Commands in das ViewModel?
Antwort: Weil es Sinn macht! Weil es 'schön' ist.
Man kann die View jederzeit austauschen. Im Idealfall kann man eine Window Phone View gegen eine WinRT View gegen eine WPF View gegen eine Silverlight View austauschen.
Ok geht nicht, weil Micrsoft nicht so genau weiss, wohin es gehen soll.
Aber dies wäre das Ideal. Und das Ideal sollte unser Ziel sein. (Deswegen wird IMO auch WP8 bald tot sein und in WinRT überführt werden)
Und ja, man kann wie früher beim MVC Pattern auch die ViewModel in die Code Behind Datei injizieren, aber es widerstrebt mir. Man muss halt die Codebehind Datei überall mit hinschleppen.

Microsoft bleibt hier seit Jahren auf der Stelle stehen. Es wurden einst ObservableCollections eingeführt, aber das IPropertyNotifyChanged Interface mit all dem Boilerplate Code muss man immer noch mitschleppen, um das Binding zu realisieren.
Microsoft spielt nicht mit, daher wird es nie richtig funktionieren. Leider.