M-V-VM è un gran bello sia chiaro ma come ogni cosa va addomesticata. Il ViewModel, come il Controller per MVC e il Presenter per MVP, è un accentratore/mediatore ergo da li si deve passare.
Traffico e rumore
Il problema è che in una applicazione desktop si ha il rischio che una singola View esponga molte funzionalità all’utente e si ha il rischio che queste funzionalità girino intorno allo stesso contesto e quindi vengano tutte implementate/esposte dallo stesso ViewModel.
Un esempio, triviale:
interface ISampleViewModel
{
    String Text { get; set; }
    Int64 Result { get; }

    ICommand SaveCommand { get; }
}
Un banalissimo ViewModel che espone un command, spesso però succede che i ViewModel devono essere trattati anche direttamente da codice e non solo via Wpf Binding, ergo si evolve verso questo:
interface ISampleViewModel
{
    String Text { get; set; }
    Int64 Result { get; }

    ICommand SaveCommand { get; }

    Boolean CanSave { get; }
    void Save();
}
Perchè “fa brutto” accedere direttamente al Command, aggiungendo però un po’ troppo rumore per i miei gusti.
Cosa serve?
A questo punto la domanda giusta è: ma cosa serve e a chi?
Una risposta possibile è che il Command a noi proprio non serve, serve solo ed esclusivamente a Wpf e al suo fantastico mondo.
Possiamo farne a meno?
Perchè no :-). Pensiamo ad un ViewModel fatto così:
interface ISampleViewModel
{
    String Text { get; set; }
    Int64 Result { get; }

    Fact CanSave { get; }
    void Save();
}
e ad una View cosà :-):
<Button Command="{cmd:AutoCommandBinding Path=SaveCommand}">My Save ButtonButton>
A parte quel Fact quale è la differenza sostanziale? Non c’è più il command che, IMHO, a noi non serve ad una cippa :-)
ndr: il nome Fact è ereditato da un vecchio post da Ayende ma l’unica cosa che eredita è il nome :-)
To be continued…
.m