views:

40

answers:

2

I am playing with a sample WPF application that is tiered in a Model-View-Presenter manner. The Model is a collection of Animals which is displayed in a view via binding to properties in a presenter class. The XAML has an items control that displays all the animals in a model.

The model class has a boolean attribute called 'IsMammal'. I want to introduce a filter in the XAML in the form of a radio button group that filters the collection of animals based on the 'IsMammal' attribute. Selection of the radiobutton 'Mammals' updates the items control with all the Animals that have the 'IsMammal' value set to true and when the value is toggled to 'Non-Mammals', the display is updated with all animals that have that particular boolean set to false. The logic to do the filtering is extremely simple. What is troubling me is the placement of the logic. I don't want any logic embedded in the *.xaml.cs. I want the toggling of the radiobutton to trigger a logic in the presenter that tapers my animal collection to be rebound to the display.

Some guidance here will be extremely appreciated.

Thanks

+1  A: 

I came from an MVP background before learning WPF and I have come to find that adapting the MVP pattern to WPF is a difficult exercise at best. The "proper" (read, least frustrating) approach is to utilize the Model-View-ViewModel (MVVM) pattern, which makes heavy use of the databinding features of WPF to minimize the amount of code that ends up the view-behind file.

In the simplest case, you would end up with two properties on your ViewModel:

  • bool FilterMammals
  • ObservableCollection MammalsToDisplay

In the XAML, You would bind the first to your radio button group and the second to the ItemsSource of the ListBox. The WPF databinding framework will call your property setter whenever the radiobutton group value changes, and in here you can filter and then update the list of items.

I'm not sure what your familiarity with MVVM is, so I'll stop here. Let me know if more detail would help :).

jgraves
@jgraves - Thanks a lot for pointing out MVVM. Details will definitely help and also it will be great to get some insight into why this approach(creating two additional properties in the Presenter and binding it to the XAML) would not work for MVP.
sc_ray
It's not that it wouldn't work for MVP, it's that creating and binding properties is fundamentally not MVP at that point (although arguably most of the UI presentation patterns overlap with each other in some fashion). You can think of MVVM as removing the "presenting" responsibility from the Presenter and letting WPF's databinding capabilities handle that. This leaves the cold, hard data behind which is essentially a model built specifically for your view, hence "View-Model". Make sense?
jgraves
+2  A: 
karmicpuppet
@karmicpuppet - Thanks. I am a little confused by the 'listControl.ItemsSource = this.lcv'. Does this mean that the Presenter class needs to be aware of the controls that are present on the view? Also for the 'OnCheckedChanged()' you mentioned how it is the RadioButton's corresponding event, can you elaborate in your example to show how the OnCheckedChange which will be defined in the presenter, is invoked by the RadioButton's on the XAML.
sc_ray
It really depends on your Presenter implementation. I was assuming that your Presenter object has a reference to the View, hence my example above. I guess the key ideas I'm trying to say are: 1) Use a ListCollectionView, and 2) Have something in the Presenter that will update the ListCollectionView's filter when the RadioButton's values get updated.
karmicpuppet
@karmicpuppet - Excellent. Thanks
sc_ray