WPF開發工具的正確應用，能夠方便的實現一些以前難以實現的圖形界面處理方法。在這里我們就先來了解一下有關WPF搜索列表的實現方法。#t#

現在很多程序都提供了搜索功能。比如MSN的Search Contract，VS和Blend里的Property Search。一般是從一個比較大的，用戶不太方便查找的列表中按關鍵字搜索符合條件的項目。

下面就來介紹一下WPF搜索列表的實現。對WPF的類庫功能不太熟悉的人可能會想到下面幾個解決方案。

1. 根據關鍵字，對List綁定到的數據源進行修改，把不符合關鍵字的數據項暫時移出列表。這個就不評價了，入門選手的方案。性能和代碼量都能讓你瞠目結舌。

2. 上面的移出列表不太好？那就不移走了，把不想看到的Item的Visibility設置成Collapsed不就行了？這是個學院派的方案，遇到一個問題解決一個，而且看上去又是那個的合情理。但是，這個要如何實現呢？不要指望直接去設置Item的Visibility，因為控件上的順序和數據上的順序不一定相同。那你就要把Visibility綁定吧。那就要到數據上加個IsMatched屬性吧。好了，現在每個Item都多了一個屬性和一個綁定。

3. 使用Converter過濾，ConverterParameter作為關鍵字。多完美啊，多么具有新創意識啊。這個是東方不敗式的方案。微軟也不是吃干飯的，如果這個Convert真是萬金油似的，它就不叫Converter了。如果沒有問題也就罷了，可這個方案的確是有問題的。問題如下。

a. Converter的返回值是一個新的List，而不是你本來打算綁定到的那個List了。也就是說ListBox的ItemsSource將綁定到一個在Converter中生成的List中。如果哪天你想得到這個List，好么，去Converter里找吧。它和Data Model根本不在一層。這時你有兩個選擇，要么破壞軟件的層次結構，要么用其它方案重寫這個功能。

b. 性能問題，筆者所在的項目就在用這個方法。當項目數超過3000時，性能就已經讓人無法忍受了。這時其實用數據綁定的角度，你沒得解決方案，無論開啟數據綁定的異步功能，還是自己用BackgroundWorker異步，都不能達到想要的效果。

當然，如果你的項目，使用Converter完全可以滿足你的要求，而且你也已經把Converter用得如火純青，那就用吧，一點問題也沒有。筆者所在項目現在就在用這個方法，因為“它可以工作，那就別去動它。”

好了，現在就來介紹目前筆者所能找到的最佳方案——使用CollectionViewSource的Filter事件，在事件處理函數中你會得到要處理的一個Item，然后你來決定這個Item是不是要顯示在界面上。這個方案是使用微軟內置的功能實現的，也就是說微軟第一次發布WPF的時候，就已經預見到了類似的需求并提供了支持，而且在他的官方示例中也演示了一翻。所心兩年前就已經有人解釋過個方案（有時要翻墻）就不足為奇了。

筆者寫了一個示例程序，即使用6000項字符串數據進行測試，速度還是很快的。

工作時常常會遇到這樣的情況，要實現諸如WPF搜索列表這樣的功能時，有時一下子就能想到很多個方案出來。然后就直接著手開始寫代碼，寫著寫著才發現吃力不討好。其實這不是努力工作，而是犯懶的表現。因為評估多個解決方案從而找出最佳方案，或是研究一個功能的Best Practice是更需要腦力的。用第一感覺寫代碼，其實只是一種純粹的體力勞動，而且不會有什么提高。“