MVVM：使用TreeViewItem中的IsExpanded和IsSelected扩展只读模型

Question

Consider a ViewModel that exposes a tree defined in the Model , which is then data-bound to a TreeView . The tree is rather large and the model is used directly because it is essentially read-only with regards to the view. Now, the TreeView lives under a TabControl in the VisualTree, so an issue at this point is that the IsExpanded and IsSelected properties aren't preserved when switching between tabs. One hesitates to add these boolean properties to each node in the Model , as this should be extended in the ViewModel as a matter of principle. The tree is composed of polymorphic nodes, so if we were to create a ViewModel node type that derives from the tree node types and adds these properties, it seems this would result in some hairy code in the ViewModel :

That is, if the tree has an abstract NodeBase , and then derived types Node1 , Node1 , ... NodeN (the Model 's Node s). The ViewModel then has to encapsulate these nodes, so when creating a ViewModelNode , if it has a reference to Node and also references to child ViewModelNode 's for each descendent ViewModelNode that encapsulates each descendent Model 's Node all the way down the tree, maintaining these child references in the ViewModel identically to how they are maintained in the Model , along with a reference to the Model . ie all references in the Model nodes are replicated in the ViewModel nodes, in order for each Model node to be encapsulated by a ViewModel node. The existence of redundant references such as this, even if handled in the ViewModelNode 's constructor, just smells bad.

What is the most accepted means to extend each node in a tree in this scenario, without wholesale replication of the references as stated above? (And to a lesser point, is the mere mention of using the model directly by the view an unforgivable crime, or is this forgiven due to the circumstances?)

Answer 1

There is perhaps an argument to be made that implementing those Boolean properties on the Model is OK, but personally I would look to creating ViewModels for each Model that's going to be in the TreeView . One advantage of doing so would perhaps be an increase in scalability, should you ever decide to implement more functionality related to the TreeView .

I think it depends on how much you are actually doing with the TreeView (within your app), but I do think the more you're doing, the stronger the argument for a ViewModel-based solution.

With regards to the hairy code, you could perhaps circumvent this to a degree by using an interface to describe your TreeView members, eg:

public interface IMyTreeViewItem
{
    bool TreeViewItemIsSelected { get; set; }
    bool TreeViewItemIsExpanded { get; set; }

    // Further potential properties

    string TreeViewItemHeaderText { get; set; }
    List<IMyTreeViewItem> TreeViewItemChildren { get; set; }
}

This approach can be used to ensure that your TreeView members are properly "subscribed". There's also then an option to reference the interface type in XAML, for example, as the TargetType of a HierarchicalDataTemplate for the TreeView .