Come creare ViewModel in MVVM per non violare il Principio di Responsabilità Singola?

Question

Robert Martin dice: "Non ci dovrebbe mai essere più di un motivo per cambiare classe".

Consideriamo la classe ViewModel associata a una vista. È possibile (o anche probabile) che ViewModel sia costituito da proprietà che non sono realmente correlate tra loro. Per le piccole viste ViewModel può essere abbastanza coerente, ma mentre l'applicazione diventa più complessa, ViewModel espone i dati che saranno soggetti a modifiche per motivi diversi e non correlati.

Dovremmo preoccuparci del principio SRP nel caso della classe ViewModel o no?

Answer 1

ViewModel ha la responsabilità unica di fornire alla vista le informazioni di cui ha bisogno. Se la vista ha bisogno di proprietà diverse e non correlate non è importante in quanto il ViewModel ha solo una ragione per cambiare e quella è la vista che mostra proprietà diverse. Quindi non dovresti preoccuparti troppo.

Detto questo, se il ViewModel diventa enorme, forse si potrebbe pensare di dividere la vista in diverse sottoview per migliorare la riusabilità e mantenere gestibili View e ViewModels.

Answer 2

Sì, ma ciò non significa che un design scadente non potrebbe costringerti a farlo.

Answer 3

Sono d'accordo con gcores.

Una volta che ViewModel diventa più di due schermate di testo, è giunto il momento di considerare la suddivisione di ViewModel in diversi modelli figlio.

Un'altra regola empirica è che non ho mai più di due livelli di annidamento nel file XAML - se una parte della vista diventa troppo complessa, è il momento per il refactoring della vista - estrai XAML interno in UserControl separato e crea ViewModel corrispondente, che sarà il contesto dati predefinito sulla vista figlio.

Answer 4

Sono d'accordo sul fatto che la suddivisione degli schermi in più viste con più ViewModel sia necessaria per ridurre la complessità e la complessità. Ecco un altro schema che ho impiegato per aiutare a rispettare SRP utilizzando MVVM:

Ecco uno scenario. My ViewModel deve ottenere dati e rispondere ai comandi di filtro dall'interfaccia utente. Creo il ViewModel per essere composito nella struttura. In altre parole, le classi figlio che hanno accesso ai membri privati ​​di ViewModel eseguono operazioni lineari come la gestione del filtro. Potrei anche avere un'altra classe figlia che esegue la logica necessaria per la selezione di elementi in base a criteri. Hai un'idea. Una volta che ViewModel sta eseguendo alcune funzioni che si estendono su diversi metodi, potrebbe essere un buon candidato delegare a una classe figlia. Le classi figlie rimangono parte del ViewModel principale, quindi è solo un modo per ridurre le dimensioni del ViewModel e rende più semplice il collaudo di queste operazioni lineari.