Should Item Grouping/Filter be in the ViewModel or View layer

mvvm

I'm in a situation where I have a list of items that need to be displayed depending on their properties. What I'm unsure of is where is the best place to put the filtering/grouping logic of the viewmodel state?

Currently I have it in my view using converters, but I'm unsure whether I should have the logic in the viewmodel?

e.g.

ViewModel Layer:

class ItemViewModel
{
    DateTime LastAccessed { get; set; }
    bool IsActive { get; set; }
}

class ContainerViewModel
{
     ObservableCollection<Item> Items {get; set;}
}

View Layer:

<TextView Text="Active Items"/>
<List ItemsSource={Binding Items, Converter=GroupActiveItemsByDay}/>
<TextView Text="Active Items"/>
<List ItemsSource={Binding Items, Converter=GroupInActiveItemsByDay}/>

or should I build it like this?

ViewModel Layer:

class ContainerViewModel
{
   ObservableCollection<IGrouping<string, Item>> ActiveItemsByGroup {get; set;}
   ObservableCollection<IGrouping<string, Item>> InActiveItemsByGroup {get; set;}
}

View Layer:

<TextView Text="Active Items"/>
<List ItemsSource={Binding ActiveItemsGroupByDate }/>
<TextView Text="Active Items"/>
<List ItemsSource={Binding InActiveItemsGroupByDate }/>

Or maybe something in between?

ViewModel Layer:

class ContainerViewModel
{
   ObservableCollection<IGrouping<string, Item>> ActiveItems {get; set;}
   ObservableCollection<IGrouping<string, Item>> InActiveItems {get; set;}
}

View Layer:

<TextView Text="Active Items"/>
<List ItemsSource={Binding ActiveItems, Converter=GroupByDate }/>
<TextView Text="Active Items"/>
<List ItemsSource={Binding InActiveItems, Converter=GroupByDate }/>

I guess my question is what is good practice in terms as to what logic to put into the ViewModel and what logic to put into the Binding in the View, as they seem to overlap a bit?

Best Answer

Grouping and filtering is one of the explicit purposes of a View Model as opposed to just using a Model. The view model takes the data from the model and organizes it precisely for the given view.

That means where a model may often be a robust data representation, and the view only needs a subsection or aggregate of that model, the view model exists to give you the data your view needs so that your view does not need to do that leg work.

It can be confusing because often times people write code that has the view going straight to the model and in these cases the view does end up responsible for this work, but if you do use view models as an intermediary, you don't need to and shouldn't be doing this non-presentational work in the view.

Related Solutions

Are value converters more trouble than they’re worth

I have used ValueConverters in some cases and put the logic in the ViewModel in others. My feeling is that a ValueConverter becomes part of the View layer, so if the logic is really part of the View then put it there, otherwise put it in the ViewModel.

Personally I don't see a problem with a ViewModel dealing with View-specific concepts like Brushes because in my applications a ViewModel only exists as a testable and bindable surface for the View. However, some people put a lot of business logic in the ViewModel (I do not) and in that case the ViewModel is more like a part of their business layer, so in that case I wouldn't want WPF-specific stuff in there.

I prefer a different separation:

View - WPF stuff, sometimes untestable (like XAML and code-behind) but also ValueConverters
ViewModel - testable and bindable class that is also WPF-specific
EditModel - part of the business layer that represents my model during manipulation
EntityModel - part of the business layer that represents my model as persisted
Repository - responsible for persistence of the EntityModel to the database

So, the way I do it, I have little use for ValueConverters

The way I got away from some of your "Con's" is to make my ViewModel's very generic. For instance, one ViewModel I have, called ChangeValueViewModel implements a Label property and a Value property. On the View there's a Label that binds to the Label property and a TextBox that binds to the Value property.

I then have a ChangeValueView which is a DataTemplate keyed off of the ChangeValueViewModel type. Whenever WPF sees that ViewModel it applies that View. The constructor of my ChangeValueViewModel takes the interaction logic it needs to refresh its state from the EditModel (usually just passing in a Func<string>) and the action it needs to take when the user edits the Value (just an Action that executes some logic in the EditModel).

The parent ViewModel (for the screen) takes an EditModel in its constructor and just instantiates the appropriate elementary ViewModels such as ChangeValueViewModel. Since the parent ViewModel is injecting the action to take when the user makes any change, it can intercept all of these actions and take other actions. Therefore, the injected edit action for a ChangeValueViewModel might look like:

(string newValue) =>
{
    editModel.SomeField = newValue;
    foreach(var childViewModel in this.childViewModels)
    {
        childViewModel.RefreshStateFromEditModel();
    }
}

Obviously the foreach loop can be refactored elsewhere, but what this does is take the action, apply it to the model, then (assuming the model has updated its state in some unknown way), tells all the child ViewModels to go and get their state from the model again. If the state has changed, they are responsible for executing their PropertyChanged events, as necessary.

That handles the interaction between, say, a list box and a details panel quite nicely. When the user selects a new choice, it updates the EditModel with the choice, and the EditModel changes the values of the properties exposed for the detail panel. The ViewModel children that are responsible for displaying the detail panel information automatically get notified that they need to check for new values, and if they've changed, they fire their PropertyChanged events.

MVVM ViewModel and Commands

The command should be on the ViewModel.

In MVVM, the ViewModel is the thing that should contain all of the logic that drives the view. The view is the simple class - just a collection of UI controls whose state is bound to properties on the ViewModel.

Josh Smith wrote a really good intro to MVVM that should clear things up for you.

Best Answer

Related Solutions

Are value converters more trouble than they’re worth

MVVM ViewModel and Commands

Related Topic