WPF Knowledge Points-DefaultView, CollectionSourceView, and CollectionView

I have been doing some things about Treeview these days and want to write some usage and experiences. When it comes to the display and performance of collection objects, collectionsourceview and collectionview play a vital role. Therefore, before writing Treeview, sort out these two classes and some related concepts separately.

Default view of WPF (DefaultView)

If data binding in WPF is directly bound to a set (the class implementing ienumerable), a view is implicitly inserted between the source set object and the target object, this view is the default view associated with the set. A view (an object that implements the icollectionview Interface) stores information about the current items in the set and supports sorting, grouping, filtering, and navigation. In fact, all sets are bound to the target object to the view of the Set, rather than directly bound to the set itself.
Let's take a look at the standard description points in msdn:
1. in WPF applications, all collections have an associated default collection view. Rather than working with the collection directly, the binding engine always accesses the collection through the Associated view.
2. an internal class based on collectionview is the default view for collections that implement only ienumerable. listcollectionview is the default view for collections that implement ilist. bindinglistcollectionview is the default view for collections that implement ibindinglistview or ibindinglist.

We can use the following code to get the default view of a set:

ICollectionView defaultView = CollectionViewSource.GetDefaultView(myCollection);

NOTE: For the sake of performance, the default view will be created as needed. That is to say, a set can have a default view. However, if the set has not been directly bound to any data, no default view is created.

 

CollectionView

The above description shows the concept and function of the default view. The next question is that WPF can implicitly create a default view. Since there is a default view, there should also be a corresponding custom view. How should we establish and use it? This is the question we will discuss right away.

Old rules, I picked out the key points in MSDN for you:

1. Represents a view for grouping, sorting, filtering, and navigating a data collection.
2. you can think of a collection view as a layer on top of a binding source collection that allows you to navigate and display the collection based on sort, filter, and group queries, all without having to manipulate the underlying source collection itself. if the source collection implements the INotifyCollectionChanged interface, the changes that raise the CollectionChanged event are propagated to the views.
3. because a view does not change the underlying source collection, a source collection can have multiple views associated with it. by using views, you can display the same data in different ways. for example, you can use two views on a collection of Task objects to show tasks sorted by priority on one part of the page and grouped by area on another part of the page.

To sum up, CollectionView is a view class. Its instances represent a View class instance. Views can be used to perform operations (grouping, sorting, filtering, navigation, etc.) on display of collection objects ). View advantages: grouping, filtering, and other operations on views do not affect the source set itself. A set can have multiple views, changes to the source set can be notified to all its views (provided that the source set implements the INotifyCollectionChanged interface ).

Obviously, the default view DefaultView is an instance of CollectionView. Although using ICollectionView to reference a view is more common, we can also:

CollectionView defaultView = CollectionViewSource.GetDefaultView(myCollection) as CollectionView;

 

CollectionViewSource
After verifying the view's real body, we are looking at our more common "real body" Auxiliary proxy.

MSDN key points:

1. CollectionViewSource is a proxy for a CollectionView class, or a class derived from CollectionView.
2. CollectionViewSource enables XAML code to set the commonly used CollectionView properties, passing these settings to the underlying view.
3. CollectionViewSource has a View property that holds the actual view and a Source property that holds the source collection.
With the previous preparations, CollectionViewSource is easy to understand. It is a proxy class of the CollectionView class for XAML. The operations on CollectionViewSource and the settings on its XAML will be applied to its CollectionView.

 

Create and use custom CollectionView

To create an IEnumerable view, we can first create A CollectionViewSource instance A and assign the set to the Source attribute of the instance, then we can get a View we need in the View attribute of the instance.
C # example:

CollectionViewSource viewSource = new CollectionViewSource();
viewSource.Source = myCollection;
ICollectionView view = viewSource.View;

XAML example (we can see that the XAML support for filtering, grouping, and sorting ):

<CollectionViewSource x:Key="myViewSource"
                        Source="{Binding Source={StaticResource MyCollection}}"
                        Filter="CollectionViewSourceFilterEvent">
<CollectionViewSource.SortDescriptions>
<SortDescription PropertyName="City"/>
</CollectionViewSource.SortDescriptions>
<CollectionViewSource.GroupDescriptions>
<PropertyGroupDescription PropertyName="Area"/>
</CollectionViewSource.GroupDescriptions>
</CollectionViewSource>

Understand CollectionView. CollectionViewSource is very important for the collection Data Binding operation. For detailed use of grouping, sorting, and other functions, I will refer to other knowledge points in the TreeView article about ing non-tree set view group display to tree multi-level structure later.