英文原文地址：Simplifying the WPF TreeView by Using the ViewModel Pattern

作者：Josh Smith

譯者按：WPF中對TreeView的操作同WinForm中有很大的不同。這篇文章講述瞭如何用ViewModel模式來簡化WPF的TreeView，個人感覺非常有價值，尤其是在WPF中思維模式跟以往有很大不同的情況下。希望能對大家有所幫助並且觸類旁通。第一次做翻譯，有錯誤的地方敬請諒解。

介紹

 這篇文章探討了如何通過使用ViewModel模式來更容易的使用WPF中的TreeView控制元件。在此過程中，我們會看到為何人們經常在使用WPF的TreeView時遇到困難，什麼是ViewModel，以及兩個例項程式，這兩個程式展現瞭如何結合TreeView和ViewModel。其中一個例項展示瞭如何建立一個具有搜尋功能的TreeView，另一個則說明了如何實現延遲載入（lazy-loading）。
 

TreeView的背景

 WPF中的TreeView控制元件揹負了一個名不副實的壞名聲。很多人嘗試著使用它，卻發現非常難用。其實問題在於人們經常試著按照Windows Forms的TreeView控制元件的使用方式來使用它。為了發揮（原文是leverage，意為槓桿作用，不好翻譯，呵呵）WPF TreeView的豐富特性，你不能再使用跟Windows Forms一樣的程式設計技術了。這也是WPF要求你為了更好恰當地使用它（指WPF）而轉換思維方式的另一個例子。畢竟我們已經走到這一步了。（原文是We aren't in Kansas anymore, Toto。來自電影《綠野仙蹤》：Toto，I've got a feeling we're not in Kansas anymore）     



 在Windows Forms中，使用TreeView非常容易，因為它非常簡單。這種簡單建立在Windows Forms的TreeView完全不靈活的事實上，比如不提供UI的虛擬化（UI virtualization），不提供外觀的個性化，同時由於它不支援資料繫結，你必須將資料存到它的節點中。WinForm的TreeView根本不夠好（原文是The WinForms TreeView is "good enough for government work"，"good enough for government work"是說不夠好）。     



 對比之下，WPF的TreeView非常的靈活，天生支援UI虛擬化（比如，TreeViewItems是按需建立created on-demand），完全允許個性化外觀，同時完全支援資料繫結。這些優秀的特性是需要代價的。他們讓WPF的TreeView比WinForm的TreeView更加複雜。一旦你學會了如何正確地使用WPF的TreeView，這些複雜性將不在話下，同時發揮WPF TreeView的全部能力將變得非常容易。



 如果你對如何個性化WPF的TreeView感興趣，可以檢視這篇文章和這篇文章。
 

ViewModel的背景

 早在2005年，John Gossman寫了一篇關於Model-View-ViewModel模式的博文，這種模式被他所在的微軟的專案組用來建立Expression Blend（即'Sparkle'）。它跟Martin Fowler的Presentation Model非常相似，唯一不同的是，它填平了presentation model和使用了WPF的豐富的資料繫結的view之間的溝壑。在Dan Crevier發表了神作DataModel-View-ViewModel series博文系列之後，(D)MVVM模式開始變得流行起來。





 (Data)Model-View-ViewModel模式跟經典的Model-View-Presenter模式很相似，除了你需要一個為View量身定製的model，這個model就是ViewModel。ViewModel包含所有由UI特定的介面和屬性，它們是輕鬆構建UI的必要元素。View繫結到ViewModel，然後執行一些命令在向它請求一個動作。而反過來，ViewModel跟Model通訊，告訴它更新來響應UI。



 這使得為應用構建UI非常的容易。往一個應用程式上貼一個介面越容易，外觀設計師就越容易使用Blend來建立一個漂亮的介面。同時，當UI和功能越來越鬆耦合的時候，功能的可測試性就越來越強。為什麼不想要一個漂亮的介面同時又有一套乾淨有效的單元測試呢？
 

究竟是什麼讓TreeView這麼難用？

 如果你的使用方法正確的話，其實TreeView是很好用的。正確的使用方法，反過來說，是根本不要直接的使用它！一般地，你需要直接地對一個TreeView設定屬性，不時地呼叫方法。這是無法逃避的，同時這麼做也沒什麼錯。不過，如果你發現你正深陷於對控制元件的呼叫（原文是the guts of the control，不好翻譯），那也許你並沒有採取最佳的方式。如果你的TreeView是資料繫結的，然後你發現你正試圖通過程式來折騰這些項，那麼你就是沒有使用正確的方法。如果你發現監聽ItemContainerGenerator的StatusChanged事件來訪問TreeViewItem的子節點，那你簡直就是脫軌了！相信我，根本沒必要這麼醜陋和困難。有更好的方法！

按照WinForm TreeView的方式來使用WPF TreeView的根本問題在於，正如我前面提到的，它們是非常不同的控制元件。WPF的TreeView允許你通過資料繫結來生成它的Items。這意味著它會為你建立TreeViewItems。由於TreeViewItems是被控制元件建立的，而不是你，因此它不能保證當你需要時，某個資料項對應的TreeViewItem還存在。你必須問問TreeView的ItemContainerGenerator是否已經為你建立了TreeViewItem。如果沒有，你必須監聽它的StatusChanged事件，當它建立了自己的子元素之後通知你。

 有趣的不止這些！如果你想獲得樹中一個非常複雜，非常深的TreeViewItem，你必須問問他的父TreeViewItem，而不是TreeView控制元件，是否它的ItemContainerGenerator已經建立了該項。但是，你要怎樣才能拿到它的父節點的引用當這個父節點還沒有被建立呢？當父節點的父節點還沒有被建立的時候又是怎樣的呢？子子孫孫，無窮潰也。這是相當痛苦的。



 正如你所見的，WPF的TreeView是一個複雜的野獸。如果你試著用錯誤的方式來使用它，將不是那麼容易的。幸運的是，如果你用正確的方式使用它，那就是小事一樁。那麼，讓我們來看看怎麼樣通過正確的方式來使用它……

ViewModel是解救的辦法

 WPF是偉大的，因為它基本上要求你分離應用程式的資料和UI。前面擊節中列出的問題都是應為違背了這個原則並且把UI當作資料儲存的地方。 一旦你不再把TreeView當成一個儲存資料的地方，而是看做一個展現資料的地方，那麼一切都將水到渠成。這就是ViewModel這個想法的由來。



 比起寫程式碼去折騰TreeView裡面的項，更好的方法是寫一個被TreeView繫結的ViewModel，然後寫程式碼來操作你的ViewModel。這不僅僅能讓你無視TreeView的複雜性，還能讓你寫出能夠很容易進行單元測試的程式碼。要為那些緊密依賴於TreeView執行時行為的類寫有意義的單元測試程式碼幾乎是不可能的，但是要為那些對這些無關行為一無所知的類寫單元測試程式碼卻很容易。



 現在，我們來看看如何實現這些概念。

示例解決方案

 這篇文章附帶了兩個示例程式，能從頁面頂部下載。該Solution包含了兩個工程。BusinessLib類庫工程包含了簡單的描述地域的類，這些類被當作純粹的資料傳輸物件。同時它還包含了一個Database類，這個類初始化資料，並且返回這些資料傳輸物件（譯者：說白了就是模擬的資料來源）。另外的一個工程，TreeViewWithViewModelDemo，包含一些示例程式。這些程式使用BusinessLib程式集中給出的資料物件，並且在放到TreeView中展示之前，把它們包裝到一個ViewModel中去。



 下面是這個Solution的一個工程樹截圖：

Demo1 - 帶文字搜尋的Family Tree

 第一個示例程式中我們構建了一個展示Family Tree的TreeView。它在介面的底部提供了搜尋的功能。截圖如下：







 當用戶輸入一些關鍵字，敲回車，或者是點選了“Find”按鈕之後，第一個匹配的專案將會被展示出來。繼續搜尋將在所有匹配項之間迴圈。所有的這些邏輯都在ViewModel中。在深入ViewModel的工作方式之前，我們先看看相關程式碼。下面是TextSearchDemoControl的後臺程式碼。

public partial class TextSearchDemoControl : UserControl
{
readonly FamilyTreeViewModel _familyTree;

public TextSearchDemoControl()
{
    InitializeComponent();

    // Get raw family tree data from a database.
    Person rootPerson = Database.GetFamilyTree();

    // Create UI-friendly wrappers around the 
    // raw data objects (i.e. the view-model).
    _familyTree = new FamilyTreeViewModel(rootPerson);

    // Let the UI bind to the view-model.
    base.DataContext = _familyTree;
}

void searchTextBox_KeyDown(object sender, KeyEventArgs e)
{
    if (e.Key == Key.Enter)
        _familyTree.SearchCommand.Execute(null);
}

}

 建構函式展示了我們如何把原始資料轉換到ViewModel中，然後把它設為UserControl的DataContext。在BusinessLib程式集中定義的Person類，非常簡單：

///
/// A simple data transfer object (DTO) that contains raw data about a person.
///
public class Person
{
readonly List _children = new List();
public IList Children
{
get { return _children; }
}

public string Name { get; set; }

}

PersonViewModel

 由於Person類是應用的資料訪問層返回的東西，它絕對不適合直接被UI使用。每個Person物件最終被包裝到一個PersonViewModel類的例項中，這樣就讓它擁有了額外的能力，比如被展開和選中。由此看出，FamilyTreeViewModel類，完成了把Person物件包裝到PersonViewModel物件中的過程，下面是它的建構函式：

public FamilyTreeViewModel(Person rootPerson)
{
_rootPerson = new PersonViewModel(rootPerson);

_firstGeneration = new ReadOnlyCollection<PersonViewModel>(
    new PersonViewModel[] 
    { 
        _rootPerson 
    });

_searchCommand = new SearchFamilyTreeCommand(this);

}

 私有的PersonViewModel的建構函式通過遞迴的方式遍歷Family Tree，把每一個Person包裝到PersonViewModel中。下面是程式碼：

public PersonViewModel(Person person)
: this(person, null)
{
}

private PersonViewModel(Person person, PersonViewModel parent)
{
_person = person;
_parent = parent;

_children = new ReadOnlyCollection<PersonViewModel>(
        (from child in _person.Children
         select new PersonViewModel(child, this))
         .ToList<PersonViewModel>());

}

 PersonViewModel有兩種成員：一種關聯到展現，另外一種關聯到Person的狀態。展現相關的屬性將會被TreeViewItem所繫結，而狀態相關的屬性繫結到TreeViewItem的內容。其中一個展現相關的屬性IsSelected，如下：

///
/// Gets/sets whether the TreeViewItem
/// associated with this object is selected.
///
public bool IsSelected
{
get { return _isSelected; }
set
{
if (value != _isSelected)
{
_isSelected = value;
this.OnPropertyChanged(“IsSelected”);
}
}
}

 這個屬性跟一個"person"沒有任何關係，而是一個簡單的用於同步View和ViewModel的狀態標識。注意屬性的setter呼叫了OnPropertyChanged方法，該方法會激發PropertyChanged事件。該事件是INotifyPropertyChanged介面的唯一成員。INotifyPropertyChanged是一個UI相關的介面，這就是為什麼PersonViewModel類實現該介面，而Person類不實現。



 一個展現相關屬性的更有趣的例子是PersonViewModel的IsExpaned屬性。這個屬性解決了怎麼保證在必要的時候，跟某個資料物件對應的TreeViewItem的展開問題。記住，如果直接用TreeView來程式設計解決這些問題，可是痛苦不堪的。

Code

 正如我前面所提到的，PersonViewModel同時還有跟Person狀態相關的屬性，比如：

Code

介面部分

 把一個TreeView繫結到PersonViewModel的程式碼是非常簡潔的。注意TreeViewItem和PersonViewModel之間的聯絡依靠的是控制元件的ItemContainerStyle：