Domanda WPF MVVM Utilizzo di comandi e gestori di eventi


Mi piace il pattern MVVM, una volta che inizi a usarlo, ne diventi dipendente.

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 atteno alla seguente regola:

Se il codice del gestore eventi manipola una porzione molto piccola della sua vista (ad esempio il gestore di eventi click sul pulsante aumenta il font di un determinato TextBlock che si trova sulla stessa vista), allora è OK 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 pensi del mio approccio?

Cosa cerchi di evitare quando usi gestori di eventi e ViewModel?

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


10
2018-04-01 11:33


origine


risposte:


Direi che la tua regola empirica non è male.

Dal mio punto di vista, la preoccupazione principale è "il codice è specifico della vista del codice o riguarda la logica aziendale?".

È corretto avere il codice nella vista, se quel codice è strettamente qui per modificare la vista e non eseguire alcun tipo di logica aziendale. 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 della vista. Se ne hai bisogno, prova a metterlo nel viewmodel.


14
2018-04-01 11:53



Penso di poter aggiungere qualcosa al commento precedente,

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


2
2017-09-22 10:45