How thick should a viewmodel be? For example, should my viewmodel or model handle the actual filtering?
For example, let's say I have a Roster object holding a collection of Users which are assigned a type (i.e. full-time, part-time, etc.). Instead of having one large viewmodel to handle the filtering of full-time or part-time (because that's what the client selected), it seems it would be better for the roster model to handle this by saying roster.GetUsersByType(type).
I have a similar issue with my Schedule object (that holds a list of events). To me it seems that since I have a master Schedule of all user's schedules, that it's better for the model to filter this and give me something like Schedule userSchedule = masterSchedule.GetScheduleOfUser(user) or Schedule selectedSchedule = masterSchedule.GetScheduleByDateInterval(dateFrom, dateTo).
Additionally, what if I wanted to swap out Views to maybe test out a new field (therefore, needing a new viewmodel), I would then need to add this filtering logic to the new viewmodel (violating DRY).
However, I'm reading a lot that the viewmodel should be thick and should handle the filtering and UI logic. Am I understanding this incorrectly? It seems that most people implement anemic domain models when doing MVVM (because that's what most of the tutorials show... e.g. for me this would be ObservableCollection in the ViewModel with a User object and Event object).
But it to seems more natural to want to push logic down into the individual components as far as I can.
