MVVM CollectionViews in WPF Application Framework (WAF)

In short my question is: How do you prefer to expose filtered/sorted/grouped ObservableCollections to Views in WAF?

I was fairly happy with my first attempt w开发者_如何转开发hich involved filtering on the VM and exposing an ICollectionView of Model objects for the View to bind to:

public StartDetailViewModel(IStartDetailView view, StartPoint start, Scenario scenario)
        : base(view)
    {
        this.scenario = scenario;
        this.start = start;

        this.startsViewSource = new CollectionViewSource();
        this.startsViewSource.Filter += new FilterEventHandler(Starts_Filter);
        this.startsViewSource.Source = scenario.Starts; 
    }
    public ICollectionView FilteredStarts
    {
        get
        {
            return startsViewSource.View;
        }
    }
    void Starts_Filter(object sender, FilterEventArgs e)
    {
        if (e.Item != null)
        {
            e.Accepted = (((StartPoint)e.Item).Date == this.start);
        }
    }
}

However, exposing the Model objects directly is insufficient since each item now needs its own ViewModel.

So, CollectionViewSource.Source is now attached to a collection of Views. The main problem with this is when applying filters:

void Starts_Filter(object sender, FilterEventArgs e)
{
    //Since e.Item is now a view we are forced to ask the View for the ViewModel:
    StartItemViewModel vm = ((IStartItemView)e.Item).GetViewModel<StartItemViewModel>();
    [...]
}

This feels wrong to me. Are there better approaches?

UPDATE

So I reverted to a CollectionViewSource.Source of Model objects and maintained a seperate collection of child View objects to which the View was bound.

The question then of course is why am I using CollectionViewSource in a ViewModel at all?

I think the following prinicple applies: If the filtering/sorting functionality is a property of the View only (i.e. an alternate view might legitimately not provide such functionality) then CollectionViews should be used in the View (with code-behind as necessary). If the filtering/sorting functionality is a dimension of the Model then this can be dealt with in the ViewModel or Model by other means.

This makes sense once you realise that code-behind in MVVM views is perfectly acceptable.

Any comments?

I think the real benefit of CollectionView lies in when you are in need of reporting information as you step through collectionview items one by one. In this way you are able to utilize the CurrentPosition property and MoveCurrentToNext (/etc.) methods which may be desireable. I particularly like the idea of being able to report PropertyChanged notifications in MVVM when item properties in the collection changed/items are added/removed/changed.

I think it just makes a bit more sense to use in controls that require more complex notifications (such as datagrid, where you may want to raise PropertyChanged events and save to your datastore each time the selectionchanges or a new item is addd to the control).

I hope that makes sense. That is just what I am putting together as a beginner.

Also, I really don't think anything should go in the code-behind of a view except a datacontext and the shared data you may be feeding it from a viewmodel.