WVF MVVM Utilizzo di comandi e gestori di eventi

Question

Mi piace lo schema MVVM, una volta iniziato a utilizzarlo, ci si diventa dipendenti.

So che nel mondo perfetto il tuo View code-behind è quasi vuoto (forse qualche codice nel costruttore) e ogni aspetto di View viene manipolato da ViewModel.

Ma ci sono momenti in cui la creazione di nuovi campi, proprietà, comandi in ViewModel crea più codice rispetto all'implementazione stessa cosa nel gestore di eventi.

Al momento mi attengo alla seguente regola:

Se codice del gestore eventi manipola porzione molto piccola della sua vista (ad esempio il tasto gestore di eventi click aumenta carattere di alcuni TextBlock che è situato sulla stessa vista) allora va bene anche implementare la logica all'interno dei gestori di eventi. Ma se View ha bisogno di manipolare la logica aziendale o accedere a risorse che sono fuori dalla vista, allora assegno queste responsabilità a ViewModel.

Cosa ne pensi del mio approccio?

Cosa si tenta di evitare quando si utilizzano gestori di eventi e ViewModel?

Quali sono le migliori pratiche consigliate quando si utilizza il pattern MVVM?

Answer 1

Direi che la regola generale non è male.

A mio avviso, la preoccupazione principale è "il codice è specifico della vista del codice o riguarda la logica aziendale?".

È OK avere il codice nella vista, se quel codice è strettamente qui per modificare la vista e non eseguire alcun tipo di logica di business. Il tuo esempio di cambiare una dimensione del font è un primo esempio di codice che è perfettamente a posto in una vista (e aumenterebbe il rumore in un ViewModel, rendendo più difficile da capire e mantenere). In sostanza, ne fai già parte se usi i trigger, quindi non è strano.

Tuttavia, se si utilizzano i test di unità, sarà molto difficile testare quel bit di logica di visualizzazione. Se ne hai bisogno, prova a metterlo nel viewmodel.

Answer 2

credo di poter aggiungere cosa per il commento precedente, nonché,

Invece di usare gestori di eventi, da molto modesta esperienza, Comandi mi danno molta più flessibilità nel senso che fornisce un meccanismo indipendente per rispondere alle eventi/azioni da diversi controlli con la possibilità di controllare lo stato del comando stesso.