簡(jiǎn)介面向WPF開(kāi)發(fā)者的MVVM入門案例包演示模型-視圖-視圖模型三層架構(gòu)在桌面應(yīng)用中的標(biāo)準(zhǔn)協(xié)作方式重點(diǎn)解決界面與業(yè)務(wù)邏輯耦合、界面更新繁瑣、測(cè)試與維護(hù)困難等實(shí)際問(wèn)題。壓縮包共42個(gè)文件主要包含C#源碼、XAML界面布局、項(xiàng)目配置文件、可執(zhí)行程序以及一份視圖分析演示文稿整體僅65KB體積小巧但工程結(jié)構(gòu)完整便于初學(xué)者直接閱讀與運(yùn)行。目前已有218人學(xué)習(xí)下載適合初學(xué)者對(duì)照學(xué)習(xí)也適合中等水平開(kāi)發(fā)者快速回顧核心概念。案例中視圖模型層完整實(shí)現(xiàn)數(shù)據(jù)雙向綁定、命令綁定、屬性變更通知機(jī)制并對(duì)模型層數(shù)據(jù)封裝、命令觸發(fā)和界面自動(dòng)刷新做了清晰示例配合可運(yùn)行的演示程序與演示文稿講解可快速掌握視圖、模型、視圖模型各層職責(zé)為后續(xù)WPF項(xiàng)目的分層設(shè)計(jì)提供可復(fù)用的參考模板也可以在此案例基礎(chǔ)上繼續(xù)擴(kuò)展依賴注入、控件模板等高級(jí)用法。 這個(gè)題目是我自己在做一個(gè)小型桌面工具時(shí)隨手寫下的但 MVVMModel-View-ViewModel這個(gè)模式一旦真正吃透你回頭看以前那些塞滿事件處理器的窗口會(huì)覺(jué)得當(dāng)初確實(shí)走了不少?gòu)澛贰＿@篇就以一個(gè)“人員信息管理”的小案例為線索把 MVVM 的拆分思路、核心基建、常見(jiàn)坑全部串起來(lái)講清楚。案例不大但該有的東西都有屬性通知、命令綁定、數(shù)據(jù)校驗(yàn)、DataGrid 行選中刪除。不管你是剛接觸 WPF 的新手還是寫了不少頁(yè)面但一直沒(méi)搞懂命令綁定和事件綁定的區(qū)別這篇都能直接照著抄。1. 為什么把 MVVM 拆成三層而不是直接寫事件很多剛開(kāi)始用 WPF 的人會(huì)有一個(gè)直接感受既然 XAML 里能綁定屬性那我在按鈕的 Click 事件里寫業(yè)務(wù)代碼不也一樣能把功能做完嗎確實(shí)能做完小工具三五天就能跑起來(lái)但等到要加功能、要重構(gòu)、要換界面的時(shí)候那種“所有邏輯都在窗體的代碼隱藏文件里”的寫法會(huì)迅速變成阻力。MVVM 的核心并不是讓你多寫幾個(gè)類而是把“界面長(zhǎng)什么樣”和“數(shù)據(jù)如何變化”徹底分開(kāi)讓兩邊可以獨(dú)立修改、獨(dú)立測(cè)試。1.1 三層的職責(zé)邊界要?jiǎng)澢宄﨧VVM 三個(gè)字母對(duì)應(yīng)三類文件職責(zé)邊界一定要?jiǎng)澢宄駝t寫著寫著就變成了“打著 MVVM 旗號(hào)的代碼后置文件”。Model 層負(fù)責(zé)數(shù)據(jù)本身它不關(guān)心界面怎么顯示。在這個(gè)人員管理案例中就是Person這個(gè)實(shí)體類里面只有屬性姓名、年齡、部門、是否在職。不持有任何界面邏輯。View 層就是 XAML 文件以及它背后的極少部分代碼只負(fù)責(zé)把 ViewModel 暴露出來(lái)的屬性和命令展示給用戶。說(shuō)白了View 就是一個(gè)“顯示器”你不在里面寫業(yè)務(wù)判斷。ViewModel 層是整個(gè)模式的靈魂它把 Model 的數(shù)據(jù)包裝成界面可以直接使用的狀態(tài)并提供命令讓 View 調(diào)用。例如刪除按鈕需要知道“當(dāng)前選中了哪一行”這個(gè)選中狀態(tài)必須存在于 ViewModel 里而不是 View 里。這個(gè)點(diǎn)是很多人初次接觸時(shí)最轉(zhuǎn)不過(guò)彎的地方明明 DataGrid 上能看到選中行為什么我不能在刪除按鈕事件里直接去拿 UI 控件上的選中項(xiàng)因?yàn)槟菢?ViewModel 就依賴了 View 的類型分層就破了。正確的做法是讓 View 把選中項(xiàng)通過(guò)綁定傳給 ViewModel 的屬性后續(xù)所有邏輯都在 ViewModel 里跑 View 完全不參與。1.2 不用 MVVM 寫事件代碼會(huì)怎樣先給大家看一段反面代碼新建一個(gè) WPF 窗口拖一個(gè) DataGrid 和一個(gè)刪除按鈕雙擊按鈕生成事件然后在事件里寫這些private void DeleteButton_Click(object sender, RoutedEventArgs e) { var grid sender as DataGrid; // 通過(guò) sender 拿控件 if (grid.SelectedItem is Person person) { _people.Remove(person); } }這個(gè)寫法不是不能用但它有以下問(wèn)題。數(shù)據(jù)集合_people是 View 字段如果以后想把這個(gè)刪除邏輯移植到另一個(gè)窗口就要復(fù)制一遍代碼。更關(guān)鍵的是如果列表數(shù)據(jù)的維護(hù)邏輯變復(fù)雜比如刪除前要彈出確認(rèn)、要級(jí)聯(lián)刪除子表、要記錄操作日志這些代碼會(huì)全部堆在按鈕事件里隨著功能增加事件方法越來(lái)越長(zhǎng)最后變成一個(gè)沒(méi)人敢動(dòng)的“上帝方法”。而 MVVM 的做法是完全不同的思路刪除邏輯寫進(jìn)命令DeleteCommand按鈕只用Command{Binding DeleteCommand}綁上去既不關(guān)心命令內(nèi)部怎么做刪除也不關(guān)心數(shù)據(jù)來(lái)自哪里。1.3 這個(gè)案例的目錄結(jié)構(gòu)這個(gè)人員管理小工具的目錄結(jié)構(gòu)如下也推薦大家新項(xiàng)目直接按這個(gè)建框架PersonManager/ ├─ Models/ │ └─ Person.cs // 數(shù)據(jù)實(shí)體 ├─ ViewModels/ │ ├─ ViewModelBase.cs // INotifyPropertyChanged 基類 │ ├─ RelayCommand.cs // ICommand 實(shí)現(xiàn) │ └─ MainViewModel.cs // 頁(yè)面主要邏輯 └─ Views/ └─ MainWindow.xaml // 界面層案例完整流程是窗口左側(cè)放一個(gè)表單可以輸入姓名、年齡、部門點(diǎn)“添加”按鈕把人加到右側(cè) DataGrid 里DataGrid 每行前面有 CheckBox勾選后點(diǎn)刪除按鈕能刪掉選中的人頂部還有一個(gè)搜索框能按姓名過(guò)濾。功能聽(tīng)起來(lái)簡(jiǎn)單但覆蓋了屬性通知、命令參數(shù)、集合數(shù)據(jù)源、數(shù)據(jù)校驗(yàn)這些 MVVM 常青知識(shí)點(diǎn)拆開(kāi)講足夠?qū)懸黄L(zhǎng)文了。2. 核心基建屬性通知和命令綁定MVVM 有一個(gè)“基礎(chǔ)設(shè)施”必須先打好否則后面所有綁定都是擺設(shè)。兩件事搭好之后剩下的就是往 XAML 里拖控件、在 ViewModel 里加屬性這么簡(jiǎn)單。2.1 INotifyPropertyChanged 和它的基類封裝WPF 的綁定系統(tǒng)能實(shí)時(shí)感知屬性變化靠的是INotifyPropertyChanged接口。只要屬性所在類實(shí)現(xiàn)了這個(gè)接口并且在屬性 setter 里觸發(fā)PropertyChanged事件界面就會(huì)自動(dòng)刷新。Model 和 ViewModel 都需要實(shí)現(xiàn)這個(gè)接口因?yàn)槎叨伎赡鼙唤壎?。在這里我封裝了一個(gè)ViewModelBase基類讓所有 ViewModel 繼承它避免每個(gè)類重復(fù)寫事件定義public class ViewModelBase : INotifyPropertyChanged { public event PropertyChangedEventHandler? PropertyChanged; protected void OnPropertyChanged([CallerMemberName] string propertyName null) { PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); } protected bool SetPropertyT(ref T field, T value, [CallerMemberName] string propertyName null) { if (EqualityComparerT.Default.Equals(field, value)) return false; field value; OnPropertyChanged(propertyName); return true; } }重點(diǎn)在于SetProperty這個(gè)方法。它先比較新舊值只有值真的變了才觸發(fā)通知避免了無(wú)意義的刷新。在實(shí)際項(xiàng)目里一套界面可能有幾十個(gè)屬性如果每個(gè) setter 都無(wú)腦觸發(fā)通知性能開(kāi)銷在復(fù)雜界面下會(huì)變得明顯。用CallerMemberName還有一個(gè)好處調(diào)用時(shí)不用手寫屬性名編輯器直接幫你把當(dāng)前屬性名傳進(jìn)去改名時(shí)也不容易漏掉。2.2 ICommand 與 RelayCommand 的兩種寫法屬性通知解決的是“數(shù)據(jù)變了界面跟著變”命令綁定解決的是“界面操作觸發(fā)了邏輯”。WPF 里按鈕的Command屬性要接受一個(gè)ICommand對(duì)象這個(gè)接口有三個(gè)成員CanExecute(object parameter)判斷命令當(dāng)前能否執(zhí)行返回 false 時(shí)按鈕自動(dòng)置灰Execute(object parameter)執(zhí)行命令邏輯CanExecuteChanged通知系統(tǒng) CanExecute 的結(jié)果變了需要重新查詢由于每次都要手寫一個(gè) ICommand 實(shí)現(xiàn)太麻煩業(yè)界通用做法是做RelayCommand。最簡(jiǎn)單版本的實(shí)現(xiàn)如下。public class RelayCommand : ICommand { private readonly Actionobject? _execute; private readonly Predicateobject?? _canExecute; public RelayCommand(Actionobject? execute, Predicateobject?? canExecute null) { _execute execute; _canExecute canExecute; } public bool CanExecute(object? parameter) { return _canExecute null || _canExecute(parameter); } public void Execute(object? parameter) { _execute(parameter); } public event EventHandler? CanExecuteChanged { add CommandManager.RequerySuggested value; remove CommandManager.RequerySuggested - value; } }這里有個(gè)細(xì)節(jié)值得多說(shuō)兩句。CanExecuteChanged的常規(guī)實(shí)現(xiàn)是直接繼承ICommand接口的事件但如果沒(méi)有特殊機(jī)制觸發(fā)它CanExecute 的變化就無(wú)法及時(shí)反映到按鈕狀態(tài)上。這里把它接到CommandManager.RequerySuggested上意思是當(dāng) WPF 的輸入系統(tǒng)檢測(cè)到界面狀態(tài)可能變化時(shí)自動(dòng)重新查詢所有命令的 CanExecute。它的底層機(jī)制是 WPF 的輸入管理器在每次鼠標(biāo)動(dòng)作、鍵盤輸入后都會(huì)觸發(fā)一次全局重查所以大多數(shù)場(chǎng)景下按鈕置灰/恢復(fù)是即時(shí)的。如果追求更精細(xì)的控制可以用帶手動(dòng)RaiseCanExecuteChanged方法的版本把刷新時(shí)機(jī)完全握在自己手里。泛型版本RelayCommandT在參數(shù)需要強(qiáng)類型時(shí)也很有用例如刪除命令需要接收一個(gè)Person對(duì)象時(shí)可以避免在 Execute 里做類型判斷。核心邏輯幾乎一樣只是把 parameter 強(qiáng)轉(zhuǎn)成T再去執(zhí)行。2.3 選 Command 而不是事件的關(guān)鍵考量同樣的按鈕點(diǎn)擊需求用事件也能實(shí)現(xiàn)但 MVVM 里選命令有幾個(gè)明確的好處。命令天然攜帶“可用/不可用”狀態(tài)按鈕的 Enabled 狀態(tài)由命令自動(dòng)控制。事件寫法中如果你要在列表為空時(shí)禁用刪除按鈕必須手動(dòng)監(jiān)聽(tīng)集合變化再去改按鈕的 IsEnabled代碼又繞又容易漏。命令寫法中CanExecute 返回SelectedPerson ! null刪除按鈕就永遠(yuǎn)跟著選中狀態(tài)走不需要寫一行界面交互代碼。命令還能天然結(jié)合輸入?yún)?shù)。DataGrid 里選中了哪一行可以通過(guò) CommandParameter 傳給命令不需要去 View 層拿控件取 SelectedItem。這就是 3.3 節(jié)會(huì)講到的核心操作方式。3. 基于人員管理案例的 MVVM 落地實(shí)現(xiàn)基建搭好現(xiàn)在進(jìn)入正題。我會(huì)按 Model→ViewModel→View 的順序把人員管理小工具的核心代碼完整列出來(lái)每個(gè)關(guān)鍵點(diǎn)都解釋為什么這么寫。3.1 Model 與 ViewModel 設(shè)計(jì)人員模型和頁(yè)面狀態(tài)Model 層的 Person 就是一個(gè)純數(shù)據(jù)類沒(méi)有界面邏輯。public class Person { public string Name { get; set; } public int Age { get; set; } public string Department { get; set; } }這里我故意沒(méi)有讓 Person 繼承 ViewModelBase因?yàn)樗菙?shù)據(jù)實(shí)體不是界面狀態(tài)。如果將來(lái) Person 要從數(shù)據(jù)庫(kù)讀出來(lái)直接用 ORM 映射到這類上完全沒(méi)有 UI 雜質(zhì)。MainViewModel 是整個(gè)頁(yè)面的核心它的字段和屬性設(shè)計(jì)如下。public class MainViewModel : ViewModelBase { private ObservableCollectionPerson _people; private Person? _selectedPerson; private string _searchText; private Person _editingPerson new Person(); private ICollectionView _peopleView; public ObservableCollectionPerson People { get; set; } public Person? SelectedPerson { get; set; } public string SearchText { get; set; } public Person EditingPerson { get; set; } }這里為什么要用ObservableCollectionPerson而不是普通的ListPerson因?yàn)镺bservableCollection實(shí)現(xiàn)了INotifyCollectionChanged只要往集合里 Add、RemoveDataGrid 會(huì)自動(dòng)刷新界面。如果用 List代碼里添加了一條數(shù)據(jù)界面卻看不到還要手動(dòng)重新給 ItemsSource 賦一次值非常別扭。EditingPerson是表單區(qū)域綁定的數(shù)據(jù)對(duì)象用戶往文本框里輸入的內(nèi)容直接寫進(jìn)這個(gè)對(duì)象。這個(gè)對(duì)象和People集合里的條目并不是同一個(gè)對(duì)象而是獨(dú)立的一個(gè)“草稿”。點(diǎn)擊“添加”命令時(shí)再把草稿內(nèi)容放入一個(gè)全新的 Person 實(shí)例添加進(jìn)集合。搜索過(guò)濾用到了ICollectionView這是 WPF 提供的一個(gè)列表視圖包裝層可以直接對(duì)它設(shè)置 Filter 委托DataGrid 綁定到視圖后會(huì)自動(dòng)展示過(guò)濾后的結(jié)果_peopleView CollectionViewSource.GetDefaultView(People); _peopleView.Filter o { if (string.IsNullOrEmpty(SearchText)) return true; return (o as Person)?.Name.Contains(SearchText) ?? false; };在SearchText的 setter 里調(diào)用_peopleView.Refresh()即可觸發(fā)重過(guò)濾。3.2 View 綁定到 ViewModelDataContext 和數(shù)據(jù)綁定ViewModel 準(zhǔn)備就緒View 的 XAML 只需要做三件事把DataContext指向 MainViewModel 實(shí)例把控件屬性綁定到對(duì)應(yīng)的 ViewModel 屬性把按鈕的Command綁定到對(duì)應(yīng)的命令屬性。主窗口的 DataContext 設(shè)置方式一般有兩種一種是代碼里在構(gòu)造函數(shù)寫DataContext new MainViewModel()另一種是 XAML 里寫Window.DataContextvm:MainViewModel //Window.DataContext。我推薦后一種因?yàn)榻缑嬖O(shè)計(jì)師不打開(kāi)代碼文件也能看到數(shù)據(jù)上下文是什么。綁定示例DataGrid ItemsSource{Binding People} SelectedItem{Binding SelectedPerson} DataGrid.Columns DataGridCheckBoxColumn Header選中 Binding{Binding IsChecked} Width50/ DataGridTextColumn Header姓名 Binding{Binding Name} Width120/ DataGridTextColumn Header年齡 Binding{Binding Age} Width80/ /DataGrid.Columns /DataGrid Button Content添加 Command{Binding AddCommand} / Button Content刪除選中 Command{Binding DeleteCommand} / TextBox Text{Binding SearchText, UpdateSourceTriggerPropertyChanged} /這是 MVVM 綁定的基本形態(tài)但有幾個(gè)坑要敲黑板。UpdateSourceTriggerPropertyChanged這個(gè)設(shè)置很關(guān)鍵。默認(rèn)情況下TextBox 的Text綁定是在失去焦點(diǎn)時(shí)才把值寫回源屬性所以如果你在表單輸入“張三”還沒(méi)點(diǎn)其他地方就想立刻拿去搜索、校驗(yàn)會(huì)拿到舊值。設(shè)成PropertyChanged后每敲一個(gè)字符都會(huì)寫回源屬性搜索過(guò)濾能做到即時(shí)響應(yīng)。SelectedItem{Binding SelectedPerson}是 DataGrid 交互的靈魂。如果不綁定這個(gè)屬性DataGrid 的選中狀態(tài)就只停留在 View 內(nèi)部ViewModel 永遠(yuǎn)不知道用戶選了哪個(gè)對(duì)象。一旦綁定ViewModel 里的SelectedPerson就會(huì)跟著用戶點(diǎn)選變化刪除命令就拿到了目標(biāo)對(duì)象。3.3 核心操作選中行刪除功能的本質(zhì)到這里我展開(kāi)講一下很多人最關(guān)心的“勾選某行點(diǎn)擊刪除”這個(gè)需求。其實(shí)需求可以拆成兩種形態(tài)兩種形態(tài)在 MVVM 下有不同的實(shí)現(xiàn)這是 WPF 新手最容易混的地方。第一種形態(tài)點(diǎn)擊行本身即選中選中后點(diǎn)刪除按鈕刪除選中行。這個(gè)最簡(jiǎn)單因?yàn)?DataGrid 的SelectedItem天然綁定到了SelectedPerson刪除命令只需要public ICommand DeleteCommand { get; } private void OnDelete() { if (SelectedPerson ! null) { People.Remove(SelectedPerson); SelectedPerson null; } }第二種形態(tài)每行前面有一個(gè) CheckBox用戶勾選多行后點(diǎn)按鈕刪除。這一種就不能只依賴 SelectedItem 了因?yàn)?CheckBox 的選中狀態(tài)和行的選中狀態(tài)是兩回事。我的做法是給 Person 模型增加一個(gè)IsChecked布爾屬性并且在 ViewModel 里準(zhǔn)備一個(gè)“所有勾選行”的集合或者干脆在刪除命令里遍歷 People 找出IsChecked true的項(xiàng)再刪除。這里有個(gè)細(xì)節(jié)DataGrid 的DataGridCheckBoxColumn綁定IsChecked之后在 MVVM 下這個(gè)屬性的變化會(huì)自動(dòng)寫回 Person 對(duì)象。所以刪除命令里直接遍歷集合即可private void OnDelete() { var toRemove People.Where(p p.IsChecked).ToList(); foreach (var p in toRemove) People.Remove(p); }為什么這里要先用ToList()再刪因?yàn)樵诒闅vPeople的同時(shí)修改ObservableCollection會(huì)引發(fā)“集合已修改”異常。先把符合條件的對(duì)象快照出來(lái)再統(tǒng)一刪除這是集合操作的基本功。CanExecute在這兩種刪除形態(tài)中也不同。按行選中刪除時(shí)CanExecute 是SelectedPerson ! null按 CheckBox 勾選刪除時(shí)由于需要實(shí)時(shí)感知IsChecked變化最省事的方案是CanExecute返回 true或者在每次刪除操作前重新判斷集合里有沒(méi)有勾選項(xiàng)然后手動(dòng)調(diào)用CommandManager.InvalidateRequerySuggested()讓所有命令重新查詢狀態(tài)。我實(shí)測(cè)下來(lái)如果追求按鈕置灰的準(zhǔn)確跟隨可以給 Person 的IsChecked屬性也實(shí)現(xiàn)PropertyChanged通知并在 setter 里觸發(fā)一次全局命令狀態(tài)刷新這樣按鈕在勾選瞬間就會(huì)亮起來(lái)。4. 數(shù)據(jù)校驗(yàn)和 ComboBox 常見(jiàn)坑MVVM 里最容易踩的第二個(gè)大坑就是表單校驗(yàn)。很多人一開(kāi)始覺(jué)得校驗(yàn)不就是在保存按鈕事件里判斷幾個(gè) TextBox 嗎但在 MVVM 下校驗(yàn)的結(jié)果要能實(shí)時(shí)反饋到界面上而且要拿干凈的數(shù)據(jù)模型這就有講究了。4.1 使用 IDataErrorInfo 做表單校驗(yàn)WPF 自帶兩個(gè)校驗(yàn)接口一個(gè)老的IDataErrorInfo一個(gè)相對(duì)新的INotifyDataErrorInfo。小項(xiàng)目用IDataErrorInfo就夠了它只有一個(gè)索引器public class Person : IDataErrorInfo { public string Name { get; set; } public int Age { get; set; } public string Error string.Empty; public string this[string columnName] { get { switch (columnName) { case nameof(Name): return string.IsNullOrEmpty(Name) ? 姓名不能為空 : ; case nameof(Age): return Age 0 || Age 150 ? 請(qǐng)輸入合法的年齡 : ; default: return ; } } } }在 XAML 里對(duì)應(yīng) TextBox 的 Binding 要加上兩個(gè)屬性TextBox Text{Binding EditingPerson.Name, ValidatesOnDataErrorsTrue, UpdateSourceTriggerPropertyChanged} /這樣一來(lái)當(dāng)用戶輸入非法數(shù)據(jù)WPF 會(huì)在控件周圍渲染一個(gè)紅色校驗(yàn)邊框不需要寫任何界面代碼。這里有個(gè)經(jīng)驗(yàn)校驗(yàn)一定要配合UpdateSourceTriggerPropertyChanged否則默認(rèn)失去焦點(diǎn)才更新源屬性用戶輸入完還沒(méi)點(diǎn)其他控件校驗(yàn)結(jié)果根本不顯示。那個(gè)“輸錯(cuò)了卻不知道哪里錯(cuò)了點(diǎn)保存才彈一堆提示框”的體驗(yàn)就是沒(méi)設(shè)這個(gè)屬性導(dǎo)致的。4.2 ComboBox 下拉框末尾空白的排查搜熱詞里有“wpf combobox 下拉框 末尾 空白”這個(gè)問(wèn)題我遇到過(guò)不下三次。典型場(chǎng)景是這樣的ComboBox 綁定了ItemsSource到一個(gè)集合下拉框打開(kāi)后最后一項(xiàng)下面多出一塊空白區(qū)域看著特別難受。這個(gè)空白區(qū)域其實(shí)不是 UI 渲染 bug而是 ComboBox 的默認(rèn)模板里下拉項(xiàng)區(qū)域的高度即使沒(méi)有內(nèi)容也會(huì)保留一個(gè)默認(rèn)的最小高度或者可能是在多選模式下最后一項(xiàng)后面被追加了一個(gè)輸入框占位符。排查時(shí)先確認(rèn) ComboBox 的IsEditable屬性是否是 true如果是那個(gè)空白通常是“可輸入文本”留下的空行把它設(shè)為 false 就能去掉。另一個(gè)更隱蔽的原因是 ComboBox 的MaxDropDownHeight設(shè)置過(guò)大而實(shí)際 ItemContainer 高度被樣式撐開(kāi)導(dǎo)致列表底部出現(xiàn)與容器高度對(duì)應(yīng)的空白。我遇到過(guò)一次是在自定義 ItemTemplate 里給每個(gè) ComboBoxItem 加了一個(gè)固定高度的邊框下拉區(qū)內(nèi)容不夠高容器底部就露出空白。解決方式是對(duì) ItemContainerStyle 設(shè)置HeightAuto或直接把MaxDropDownHeight調(diào)小。如果你也遇到類似現(xiàn)象建議第一步不是去網(wǎng)上搜答案而是打開(kāi) Snoop 或 Live Visual Tree 看下拉區(qū)域的實(shí)際尺寸這個(gè)比盲猜效率高得多。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄MVVM 的模式本身不復(fù)雜真正勸退人的是那些莫名其妙的“小現(xiàn)象”。這里把我實(shí)際遇到過(guò)的幾個(gè)高頻問(wèn)題和排查辦法列成清單建議直接收藏備用。以下問(wèn)題都基于 .NET 8 WPF如果版本不同個(gè)別細(xì)節(jié)可能有差異但排查思路通用。5.1 DataGrid 選中行默認(rèn)背景色的調(diào)整DataGrid 的行被選中時(shí)默認(rèn)是一整行藍(lán)色背景很多界面設(shè)計(jì)里并不想要這種效果或者想換成跟隨主題的淺灰色。由于 WPF 的默認(rèn)樣式層級(jí)很深光改RowBackground往往沒(méi)用正確做法是覆寫DataGridRow的IsSelected觸發(fā)器。一個(gè)簡(jiǎn)潔的寫法是給 DataGrid 加CellStyle把選中單元格的背景設(shè)置成透明或自定義色DataGrid.CellStyle Style TargetTypeDataGridCell Style.Triggers Trigger PropertyIsSelected ValueTrue Setter PropertyBackground Value#E8F0FE / Setter PropertyBorderThickness Value0 / /Trigger /Style.Triggers /Style /DataGrid.CellStyle我踩過(guò)的一個(gè)坑是這個(gè) Style 如果放在DataGrid.Resources里而不設(shè)置x:Key某些版本下會(huì)被DataGridCheckBoxColumn的單元格忽略導(dǎo)致勾選列的選中背景色改不干凈。最省心的方式是直接放在CellStyle里全局生效。如果仍然改不掉多半是你的控件用到了第三方主題或自定義主題資源優(yōu)先檢查主題包是否在你之前覆蓋過(guò)這套 Style。5.2 提示找不到 BindableProperty 或?qū)傩月窂綗o(wú)效這種報(bào)錯(cuò)一般出現(xiàn)在綁定寫錯(cuò)或數(shù)據(jù)上下文類型不對(duì)時(shí)。常見(jiàn)的有兩種第一種是 XAML 里寫了{(lán)Binding SelectedPerson.Name}但當(dāng)前控件的 DataContext 不是 MainViewModel于是解析不出來(lái)第二種是拼寫錯(cuò)了屬性名編譯期不報(bào)錯(cuò)運(yùn)行期輸出綁定失敗提示。排查技巧是先看輸出窗口有沒(méi)有BindingExpression path error之類的紅色提示。它會(huì)把目標(biāo)屬性、源屬性名、錯(cuò)誤原因一起列出來(lái)。然后尤其要檢查 DataContext 是不是傳到了子控件。很多人只在 Window 根節(jié)點(diǎn)設(shè)了 DataContext但彈窗、用戶控件單獨(dú)存在它們的 DataContext 是 null綁不定就自然報(bào)錯(cuò)。寫業(yè)務(wù)代碼時(shí)我習(xí)慣在用到一個(gè)復(fù)雜綁定的控件上臨時(shí)打開(kāi) Live Property Explorer 看 DataContext 的實(shí)際類型和屬性值。5.3 WPF 與 WinForm 選型對(duì)比熱詞里有“工控 WPF 為何替代不了 WinForm”這個(gè)說(shuō)法這個(gè)觀點(diǎn)放在十年前有道理放在今天就不一定了。早期 WPF 的渲染性能、數(shù)據(jù)綁定體系確實(shí)對(duì)老工控機(jī)不太友好但這幾年 .NET 的持續(xù)優(yōu)化和 WPF 的硬件加速改進(jìn)已經(jīng)讓它跑得很穩(wěn)定了。而且 WPF 在自定義控件、動(dòng)畫、數(shù)據(jù)可視化上的優(yōu)勢(shì)是 WinForm 完全沒(méi)法比的DataGrid 內(nèi)置虛擬化就比 DataGridView 強(qiáng)很多。選型時(shí)重點(diǎn)考慮三點(diǎn)就夠了。項(xiàng)目成員長(zhǎng)期只熟悉 WinForm且界面需求簡(jiǎn)單、表格邏輯重那 WinForm 肯定效率更高項(xiàng)目需要現(xiàn)代化界面、動(dòng)態(tài)數(shù)據(jù)展示、自定義控件那 WPF 的 MVVM 開(kāi)發(fā)效率會(huì)反超后面維護(hù)成本也低第三方控件庫(kù)成本也是一個(gè)考量因?yàn)闆](méi)有商業(yè)庫(kù)的 WPF 也能通過(guò) Style 和模板做出好看界面而 WinForm 做高級(jí)界面基本要靠第三方控件來(lái)湊。6. 寫在最后的一點(diǎn)個(gè)人體會(huì)MVVM 這個(gè)模式難點(diǎn)不在代碼怎么寫而在思維方式的轉(zhuǎn)變。你需要從“點(diǎn)擊按鈕操作界面控件”切換成“用戶操作觸發(fā)了某個(gè)命令命令操作了數(shù)據(jù)界面由于數(shù)據(jù)變化自然響應(yīng)”。這個(gè)轉(zhuǎn)變第一次做會(huì)覺(jué)得繞但當(dāng)你把 ViewModel 里的一堆邏輯復(fù)制到另一個(gè)窗口只用改一行綁定的時(shí)候你就能體會(huì)到這種分層帶來(lái)的紅利。新項(xiàng)目的建議是把基類和命令封裝做到位后面每加一個(gè)頁(yè)面其實(shí)就是往目錄里加兩個(gè)文件ViewModel XAML大部分代碼都是機(jī)械操作。另外一個(gè)小技巧是如果你在做后端接口對(duì)接讓 Model 類直接對(duì)應(yīng)后端返回的 JSON 結(jié)構(gòu)View 層只做展示這樣整個(gè)系統(tǒng)的數(shù)據(jù)流會(huì)非常干凈。本文還有配套的精品資源點(diǎn)擊獲取