Quanto dovrebbe essere spessa una visuale? Ad esempio, il mio modello di vista o modello dovrebbe gestire il filtro effettivo?
Ad esempio, supponiamo di avere un oggetto Roster contenente una raccolta di Utenti a cui è assegnato un tipo (ad esempio, a tempo pieno, part-time, ecc.). Invece di avere un grande viewmodel per gestire il filtraggio di full-time o part-time (perché è ciò che il client ha selezionato), sembra che sarebbe meglio per il modello di ruolo gestirlo dicendo roster.GetUsersByType(type) .
Ho un problema simile con il mio oggetto Schedule (che contiene un elenco di eventi). A me sembra che, dal momento che ho un programma principale di tutte le pianificazioni dell'utente, è meglio che il modello lo filtri e mi dia qualcosa come Schedule userSchedule = masterSchedule.GetScheduleOfUser(user) o Schedule selectedSchedule = masterSchedule.GetScheduleByDateInterval(dateFrom, dateTo) .
Inoltre, se volessi scambiare le Views per testare un nuovo campo (quindi, necessitavo di un nuovo viewmodel), dovrei quindi aggiungere questa logica di filtraggio al nuovo viewmodel (violando DRY).
Tuttavia, sto leggendo molto che il viewmodel dovrebbe essere spesso e dovrebbe gestire il filtraggio e la logica dell'interfaccia utente. Sto comprendendo questo in modo errato? Sembra che molte persone implementino modelli di dominio anemici quando eseguono MVVM (perché è quello che mostra la maggior parte delle esercitazioni ... ad esempio, per me questo sarebbe ObservableCollection nel ViewModel con un oggetto User e un oggetto Event).
Ma sembra più naturale voler spingere la logica verso il basso nei singoli componenti il più lontano possibile.