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

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

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

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

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

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

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

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

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

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

筆者寫了一個示例程序，即使用6000項字符串?dāng)?shù)據(jù)進行測試，速度還是很快的。

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