The WPF TreeView is a View of a Tree

I have been thinking a lot about the WPF TreeView control lately.  My recent article about it, which, by the way, is my wedding gift to Sacha Barber, discusses how the ideal way of working with a TreeView is to bind it to a ViewModel, and then program against the ViewModel.  This got me thinking.

When I first started learning about Windows Forms, I thought the TreeView control had a strange name.  Why not call it the Tree control?  Why did they add the word “View” to the end?  At the time, the .NET 1.0 era, I don’t think any other control had the word “View” tacked onto the end of its name, except for ListView.  After a while, I got used to the name and never gave it much thought, until now.

The WinForms TreeView control is not really providing a “view” of a tree: it is the tree.  You create a tree data structure in the control, where each node in the tree is of type TreeNode, and the control renders those nodes.  One could argue that the WinForms TreeView control’s name is a misnomer, because it can only show its own TreeNodes.  By the same reasoning, we should call the Menu a MenuView and the ComboBox a ComboBoxView, but that is not the case.  WinForms should have a Tree control instead of a TreeView control.

The WPF TreeView control is very different.  Granted, at the end of the day, it still has a tree data structure consisting of TreeViewItem objects, but the similarities end there.  We can use the TreeView in our WPF programs to literally provide a view of a tree.  The fact that the WPF TreeView supports data binding allows us to create a tree data structure, perhaps of custom ViewModel objects, and provide it to the TreeView control’s ItemsSource property.  At that point, the TreeView will do all the grunt work of creating TreeViewItems and hooking them together for us.  We are not required to focus much on the TreeView, but more on the data we actually care about.

We can provide in-depth customizations for how the TreeView renders the items, by setting properties such as ItemContainerStyle to affect properties of every TreeViewItem, and ItemTemplate to specify what each item should look like and where its child items come from.  We declare all of this in XAML, and let TreeView handle all the details of applying our styles and templates. We can remain focused on the tree data structure, it’s behavior, it’s state, and just tell the TreeView how we want to view the tree.

It might seem like a minor difference, but, in my opinion, it represents a significant change of mindset.  In WPF, the TreeView control provides a view of a tree.