簡(jiǎn)介面向WPF/.NET開發(fā)者的DataGrid動(dòng)態(tài)列源碼示例核心解決表格列需要在運(yùn)行時(shí)按數(shù)據(jù)模型自動(dòng)生成的問題。實(shí)現(xiàn)思路涵蓋反射讀取屬性生成列、列集合動(dòng)態(tài)管理、自定義編輯模板、保存取消命令及數(shù)據(jù)驗(yàn)證等環(huán)節(jié)適合正處于MVVM學(xué)習(xí)階段、或需要為表格實(shí)現(xiàn)動(dòng)態(tài)列與可編輯單元格的C#桌面開發(fā)者參考。壓縮包共43個(gè)文件、約88KB主體為17個(gè)C#源碼文件包含視圖模型、動(dòng)態(tài)列生成類、實(shí)體模型及兩個(gè)XAML界面另有工程配置、編譯產(chǎn)物和輔助調(diào)試文件三層代碼結(jié)構(gòu)完整且可直接運(yùn)行。該資源已有2931人學(xué)習(xí)瀏覽體量小而實(shí)用讀者可借助源碼掌握動(dòng)態(tài)列與編輯模板的綁定寫法、雙向同步與校驗(yàn)邏輯也可先運(yùn)行編譯好的程序觀察效果再對(duì)照代碼理解能有效縮短WPF下MVVM模式的入門與排錯(cuò)時(shí)間。 做動(dòng)態(tài)列需求前我一直以為WPF里DataGrid的列綁定是件很順手的事。直到接了一個(gè)上位機(jī)報(bào)表的項(xiàng)目接口返回的字段列表是運(yùn)行時(shí)才確定的列名可能今天叫A明天叫B客戶還要求不同的列用不同的輸入控件數(shù)字列要能輸小數(shù)、狀態(tài)列要下拉選擇、日期列要點(diǎn)出日歷。那會(huì)兒才意識(shí)到DataGrid的Columns在MVVM里就是一塊硬骨頭它根本不支持從ViewModel直接綁定。這篇文章把我后來沉淀下來的完整方案拆開講包括動(dòng)態(tài)行模型、列定義模型、動(dòng)態(tài)列生成、單元格編輯器切換以及在刷屏量級(jí)數(shù)據(jù)下踩過的各種坑給同樣被動(dòng)態(tài)列折磨的人一個(gè)可以直接抄作業(yè)的存檔。1. 動(dòng)態(tài)列到底難在哪DataGrid與MVVM的適配層裂縫1.1 從一次上位機(jī)報(bào)表需求說起當(dāng)時(shí)的需求其實(shí)并不復(fù)雜數(shù)據(jù)源來自一個(gè)通用查詢接口返回字段清單和行數(shù)據(jù)字段數(shù)量、字段類型、字段順序全部動(dòng)態(tài)。也就是說ViewModel里不可能寫死一個(gè)包含固定屬性集合的實(shí)體類也不可能在XAML里預(yù)置死若干個(gè)DataGridTextColumn?？蛻暨€提了兩個(gè)附加要求不同字段要用合適的編輯器輸入文本、數(shù)字、下拉、日期以及列的顯示隱藏希望在運(yùn)行時(shí)通過菜單切換。這兩個(gè)要求單獨(dú)看不難但疊加上MVVM三個(gè)字麻煩就來了。如果你用AutoGenerateColumns DataTable偷懶列確實(shí)能自動(dòng)生成但編輯器完全不可控默認(rèn)文本綁定、類型轉(zhuǎn)換、下拉列、日期列全都得另想辦法更別提把列顯隱和用戶配置序列化回ViewModel了。1.2 為什么 DataGrid.Columns 不能直接綁定DataGrid.Columns是ObservableCollectionDataGridColumn類型按道理是支持監(jiān)聽的。但問題在于DataGrid內(nèi)部并不會(huì)在Columns集合變化時(shí)重新生成可見列或者準(zhǔn)確說它只監(jiān)聽集合的增刪事件來同步UI可你很難把一個(gè)DataGridTextColumn序列化為配置存到數(shù)據(jù)庫也很難把它作為純數(shù)據(jù)對(duì)象綁定到ViewModel。更本質(zhì)的問題是DataGridColumn不是依賴對(duì)象能直接“用數(shù)據(jù)驅(qū)動(dòng)”的那種模型。它的Header、Binding等屬性雖然有些是依賴屬性但整個(gè)Columns集合是控件內(nèi)部的UI集合不屬于DataContext的數(shù)據(jù)范圍。你要在MVVM里動(dòng)態(tài)生成列本質(zhì)上是在“數(shù)據(jù)模型”和“控件元素”之間做翻譯這個(gè)翻譯層要么寫在View的代碼后臺(tái)要么封裝成附加行為。1.3 三個(gè)必須拆分的設(shè)計(jì)層面做完這個(gè)項(xiàng)目后我的結(jié)論是動(dòng)態(tài)列必須拆成三層來看。數(shù)據(jù)源層提供行的數(shù)據(jù)行不再是一個(gè)固定實(shí)體類而是一個(gè)可以按字段名取值的動(dòng)態(tài)容器。列定義層描述每一列的信息標(biāo)題、綁定路徑、寬度、類型、編輯器類型、是否只讀、是否可見。UI生成層根據(jù)列定義創(chuàng)建對(duì)應(yīng)的DataGridColumn并處理增刪、顯隱、寬度變化等UI操作。這三層各管各的ViewModel只管前兩層UI生成層用附加屬性或輕量代碼后臺(tái)承載。這樣既保住了MVVM的數(shù)據(jù)驅(qū)動(dòng)優(yōu)勢(shì)又不用把UI細(xì)節(jié)塞進(jìn)ViewModel。2. 動(dòng)態(tài)行的數(shù)據(jù)層設(shè)計(jì)字典行模型與索引器通知2.1 為什么不用DataTable很多人第一反應(yīng)是DataTable畢竟它能動(dòng)態(tài)加列加行配合AutoGenerateColumns也很省事。但DataTable放在MVVM里會(huì)有幾個(gè)致命問題。第一DataTable的行是DataRowView綁定到DataGrid后類型信息很弱校驗(yàn)、格式化都得依賴DataTable的列類型配置但列類型又是全局的沒法做到同一個(gè)列在不同行有不同的編輯器行為。第二DataTable和ViewModel之間缺一層映射你很難把業(yè)務(wù)校驗(yàn)、命令、按鈕列這些邏輯掛到行對(duì)象上。第三DataTable自帶的通知機(jī)制在WPF里偶爾會(huì)有刷新時(shí)機(jī)的問題尤其是編輯后立即排序、篩選偶爾會(huì)出現(xiàn)值對(duì)不上的詭異現(xiàn)象。所以對(duì)于中大型項(xiàng)目我更推薦自己做一個(gè)“動(dòng)態(tài)行”容器而不是直接用DataTable。2.2 DynamicRow內(nèi)核字典加索引器加INPC動(dòng)態(tài)行的核心其實(shí)就是一個(gè)字典加一個(gè)索引器屬性public class DynamicRow : ObservableObject { private readonly Dictionarystring, object? _values new(StringComparer.OrdinalIgnoreCase); public object? this[string key] { get _values.TryGetValue(key, out var v) ? v : null; set { if (_values.TryGetValue(key, out var old) Equals(old, value)) return; _values[key] value; OnPropertyChanged(key); // 通知對(duì)應(yīng)列的綁定刷新 OnPropertyChanged(Item[]); // 兼容集合索引器監(jiān)聽 } } public IReadOnlyDictionarystring, object? Values _values; }這里有一個(gè)細(xì)節(jié)必須提醒如果只發(fā)OnPropertyChanged(key)在多數(shù)場(chǎng)景下DataGrid的單元格能刷新但如果有人用CollectionViewSource對(duì)動(dòng)態(tài)行做了分組或排序或者綁定了ItemsSource的路徑索引就必須額外發(fā)一個(gè)Item[]通知否則部分場(chǎng)景刷新不到。2.3 索引器通知觸發(fā)機(jī)制的原理為什么CollectionView會(huì)監(jiān)聽I(yíng)tem[]這種偽屬性名因?yàn)閃PF的綁定引擎把this[string key]這類索引器當(dāng)成一個(gè)名為Item[]的屬性來看待。當(dāng)綁定路徑是[OrderQty]時(shí)綁定引擎實(shí)際監(jiān)聽的是Item[]這個(gè)屬性的PropertyChanged事件然后把變更結(jié)果映射到對(duì)應(yīng)索引鍵上。所以只發(fā)OrderQty通知能作用到顯式綁定{Binding OrderQty}的地方但索引器綁定{Binding [OrderQty]}不一定都能收到穩(wěn)妥做法是兩者都發(fā)。實(shí)際項(xiàng)目里我還遇到過一個(gè)坑如果字典里存的是decimal而綁定的源是double值寫進(jìn)去再讀出來類型是不一致的。所以DynamicRow的賦值入口我會(huì)做一層統(tǒng)一轉(zhuǎn)換public void SetValue(string key, object? value, Type targetType) { if (value ! null targetType ! null) { var converted Convert.ChangeType(value, targetType); this[key] converted; } else { this[key] value; } }這樣列定義里只要聲明類型寫入的值就不會(huì)因?yàn)閿?shù)據(jù)結(jié)構(gòu)混亂導(dǎo)致后端序列化出問題。3. 列定義模型把Columns翻譯成ViewModel能管的數(shù)據(jù)3.1 ColumnMeta列的一切信息都在這里動(dòng)態(tài)列的源頭是ColumnMeta它是列在ViewModel世界里的化身。我給它的最小定義大致是這樣public enum CellEditorKind { Text, // 文本框 Numeric, // 數(shù)字輸入 ComboBox, // 下拉選擇 DatePicker, // 日期選擇 CheckBox, // 布爾勾選 Button // 命令按鈕 } public class ColumnMeta : ObservableObject { public string BindingPath { get; set; } string.Empty; public string Header { get; set; } string.Empty; public Type DataType { get; set; } typeof(string); public int Width { get; set; } 120; private CellEditorKind _editorKind CellEditorKind.Text; public CellEditorKind EditorKind { get _editorKind; set { if (SetProperty(ref _editorKind, value)) OnPropertyChanged(nameof(Template)); } } public bool IsReadOnly { get; set; } private bool _visible true; public bool Visible { get _visible; set SetProperty(ref _visible, value); } public IEnumerable? Options { get; set; } // ComboBox數(shù)據(jù)源 public ICommand? Command { get; set; } // 按鈕列命令 public string? CommandParameterPath { get; set; } public ObservableCollectionColumnMeta? Children { get; set; } // 表頭分組的進(jìn)階玩法 }這里我把EditorKind與模板資源隔離ViewModel里面不直接持有一個(gè)DataTemplate對(duì)象只聲明編輯器類型。UI生成層拿到EditorKind再去查對(duì)應(yīng)的模板資源這樣ViewModel可以不引用任何UI命名空間。3.2 附加屬性讓Columns變得可觀察有了列定義集合后View層需要把它翻譯成DataGrid.Columns。我封裝了一個(gè)附加屬性掛在DataGrid上public static class DataGridColumnsBehavior { public static readonly DependencyProperty BindableColumnsProperty DependencyProperty.RegisterAttached( BindableColumns, typeof(ObservableCollectionColumnMeta), typeof(DataGridColumnsBehavior), new PropertyMetadata(null, OnBindableColumnsChanged)); public static void SetBindableColumns(DependencyObject element, ObservableCollectionColumnMeta value) element.SetValue(BindableColumnsProperty, value); public static ObservableCollectionColumnMeta GetBindableColumns(DependencyObject element) (ObservableCollectionColumnMeta)element.GetValue(BindableColumnsProperty); private static void OnBindableColumnsChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { if (d is not DataGrid grid) return; if (e.OldValue is ObservableCollectionColumnMeta oldList) oldList.CollectionChanged - OnColumnCollectionChanged; if (e.NewValue is ObservableCollectionColumnMeta newList) newList.CollectionChanged OnColumnCollectionChanged; grid.Columns.Clear(); foreach (var meta in (IEnumerableColumnMeta?)e.NewValue ?? Enumerable.EmptyColumnMeta()) { grid.Columns.Add(CreateColumn(meta)); } } private static void OnColumnCollectionChanged(object? sender, NotifyCollectionChangedEventArgs e) { // 拿到DataGrid實(shí)例根據(jù)e.Action對(duì)grid.Columns做增量處理 } }這段代碼的核心思想是ViewModel里維護(hù)一個(gè)ObservableCollectionColumnMeta所有列的新增、刪除、順序調(diào)整都走集合事件附加屬性負(fù)責(zé)把變更同步到UI的DataGrid.Columns。有一個(gè)關(guān)鍵點(diǎn)DataGrid.Columns里每一項(xiàng)是DataGridColumn它們不是普通的輕量對(duì)象頻繁整體Clear再重建會(huì)導(dǎo)致視覺閃爍、列寬丟失還有可能短暫破壞虛擬化狀態(tài)。所以集合事件里盡量做增量增刪而不是每次都清空重建。3.3 創(chuàng)建DataGridColumn的方法每個(gè)ColumnMeta對(duì)應(yīng)一個(gè)DataGridTemplateColumn模板根據(jù)EditorKind來選private static DataGridColumn CreateColumn(ColumnMeta meta) { var column new DataGridTemplateColumn { Header meta.Header, Width new DataGridLength(meta.Width), IsReadOnly meta.IsReadOnly }; if (!meta.IsReadOnly) { column.CellTemplate CellTemplateFactory.CreateDisplayTemplate(meta); column.CellEditingTemplate CellTemplateFactory.CreateEditTemplate(meta); } else { column.CellTemplate CellTemplateFactory.CreateDisplayTemplate(meta); } return column; }CellTemplateFactory是一個(gè)純UI層的輔助類負(fù)責(zé)按EditorKind構(gòu)建具體模板。這個(gè)工廠放在View層很正常它解決的是把列定義轉(zhuǎn)成UI這個(gè)純表現(xiàn)問題。重要提醒DataGridTemplateColumn在非編輯態(tài)默認(rèn)不加載CellEditingTemplate所以要在展示和編輯之間做不同的樣式這個(gè)機(jī)制是天然的不要為了編輯樣式去污染CellTemplate。4. 單元格編輯器動(dòng)態(tài)切換從文本到下拉到日期4.1 顯示模板與編輯模板的分工在DataGrid里CellTemplate負(fù)責(zé)非編輯狀態(tài)下的呈現(xiàn)一般是一個(gè)只讀的TextBlockCellEditingTemplate才是編輯器真正的交互控件在進(jìn)入編輯模式以后才會(huì)被加載。這個(gè)分工是我實(shí)現(xiàn)動(dòng)態(tài)編輯器的關(guān)鍵顯示模板決定看起來是什么編輯模板決定點(diǎn)進(jìn)去怎么改。比如Numeric類型的列顯示模板我還是用TextBlock直接展示數(shù)值編輯模板換成帶數(shù)值校驗(yàn)的TextBoxComboBox類型的列顯示模板是TextBlock顯示當(dāng)前選中值編輯模板是ComboBox下拉。這樣列在視覺上很干凈編輯體驗(yàn)又靈活。4.2 動(dòng)態(tài)構(gòu)造編輯模板我用的方法是代碼動(dòng)態(tài)構(gòu)造DataTemplate。雖然FrameworkElementFactory在.NET Core 3.0以后進(jìn)入了維護(hù)模式官方更推薦XamlReader或者直接寫XAML模板但在動(dòng)態(tài)生成、模板結(jié)構(gòu)由枚舉值決定的場(chǎng)景下FrameworkElementFactory仍然是最直接的工具實(shí)測(cè)在.NET 8的WPF項(xiàng)目里能穩(wěn)定工作。文本編輯器的構(gòu)建public static DataTemplate CreateEditTemplate(ColumnMeta meta) { var textBox new FrameworkElementFactory(typeof(TextBox)); textBox.SetBinding(TextBox.TextProperty, new Binding($[{meta.BindingPath}]) { Mode BindingMode.TwoWay, UpdateSourceTrigger UpdateSourceTrigger.PropertyChanged }); var template new DataTemplate { VisualTree textBox }; template.Seal(); return template; }Numeric可以在需要時(shí)給TextBox的PreviewTextInput掛事件但事件掛在工廠上會(huì)比較繞。我一般換成在控件里放一個(gè)輕量驗(yàn)證的依賴屬性或者干脆依賴綁定層的類型轉(zhuǎn)換。下拉編輯器public static DataTemplate CreateComboBoxEditTemplate(ColumnMeta meta) { var combo new FrameworkElementFactory(typeof(ComboBox)); combo.SetBinding(ComboBox.SelectedValueProperty, new Binding($[{meta.BindingPath}]) { Mode BindingMode.TwoWay, UpdateSourceTrigger UpdateSourceTrigger.PropertyChanged }); combo.SetBinding(ComboBox.ItemsSourceProperty, new Binding(nameof(ColumnMeta.Options)) { Source meta }); var template new DataTemplate { VisualTree combo }; template.Seal(); return template; }注意這里ItemsSource的Binding把Source指定為ColumnMeta實(shí)例本身而不是行數(shù)據(jù)。這保證所有行的下拉列表共享同一個(gè)Options集合不受DataContext變化的影響。這也是我前文說的列元數(shù)據(jù)閉包技巧。日期和勾選列同理只是換成DatePicker和CheckBox。4.3 運(yùn)行時(shí)切換編輯器類型如果需求是用戶切換某列類型后編輯器跟著變那ColumnMeta里必須有EditorKind變更的通知然后UI層要處理列模板的替換。在附加屬性的集合事件里對(duì)單列的EditorKind變更我建議直接找到DataGrid.Columns里對(duì)應(yīng)的那一列替換它的CellTemplate和CellEditingTemplateprivate static void OnColumnMetaEditorKindChanged(ColumnMeta meta) { if (meta.Tag is DataGridTemplateColumn column) { column.CellTemplate CellTemplateFactory.CreateDisplayTemplate(meta); column.CellEditingTemplate CellTemplateFactory.CreateEditTemplate(meta); column.IsReadOnly meta.IsReadOnly; } }為了讓ColumnMeta能快速定位到UI列可以在創(chuàng)建列時(shí)給DataGridTemplateColumn.Tag賦上ColumnMeta實(shí)例也可以在字典里維護(hù)映射。我習(xí)慣用Tag簡(jiǎn)單直接但Tag本身是object類型使用時(shí)要小心線程訪問。5. 穩(wěn)定性和性能刷新、篩選、大數(shù)據(jù)量的實(shí)操?gòu)?fù)盤5.1 數(shù)據(jù)刷新不閃爍最早我偷懶刷新時(shí)直接dataGrid.ItemsSource null; dataGrid.ItemsSource rows;這種寫法在數(shù)據(jù)量小的時(shí)候還能忍數(shù)據(jù)量一上來就是明顯的白屏閃爍、滾動(dòng)位置丟失體驗(yàn)很差。應(yīng)改用ICollectionView統(tǒng)一管理public ICollectionView RowsView { get; } RowsView CollectionViewSource.GetDefaultView(Rows); // 刷新時(shí) RowsView.Refresh();如果你的數(shù)據(jù)源是ObservableCollectionDynamicRow且行內(nèi)修改走的是索引器INPC其實(shí)多數(shù)情況下不需要全局Refresh。只有篩選條件、排序規(guī)則變化時(shí)才需要調(diào)用Refresh。配合ICollectionView的LiveFiltering還能實(shí)現(xiàn)動(dòng)態(tài)篩選但要注意開啟IsLiveFiltering需要數(shù)據(jù)源支持屬性通知DynamicRow已經(jīng)天然支持了。5.2 列集合增量更新OnColumnCollectionChanged里不要梭哈Clear和Addall。增刪列的時(shí)候?qū)?yīng)到DataGrid.Columns的Index位置做Insert和RemoveAt視覺上幾乎無感。排序變化則用Move方法。這里有一個(gè)我踩過的坑DataGridTemplateColumn的引用一旦從Columns里移除再插回去模板和綁定經(jīng)常會(huì)丟狀態(tài)尤其是那列正在被編輯時(shí)。所以我處理刪除時(shí)如果那列正處于編輯態(tài)會(huì)先讓DataGrid結(jié)束編輯再刪grid.CommitEdit(DataGridEditingUnit.Cell, true); grid.CancelEdit(DataGridEditingUnit.Row);否則偶爾會(huì)拋出指定元素已經(jīng)是另一個(gè)元素的邏輯子元素之類的異常排查起來相當(dāng)費(fèi)時(shí)間。5.3 大數(shù)據(jù)量下的字典性能DynamicRow用Dictionary存儲(chǔ)行數(shù)到十萬級(jí)時(shí)滾動(dòng)性能受兩個(gè)因素影響。一是每次綁定取值都要查字典但DataGrid在虛擬化模式下只求值可見單元格所以實(shí)際開銷可控二是排序和分組的時(shí)候CollectionView會(huì)頻繁調(diào)用屬性獲取字典查找比實(shí)體類字段反射慢不少。經(jīng)驗(yàn)數(shù)據(jù)十萬行、三十列以內(nèi)普通機(jī)器上滾動(dòng)流暢度還能接受超過這個(gè)量級(jí)建議把DynamicRow改為編譯后的強(qiáng)類型行或改用表達(dá)式樹生成的屬性訪問器。在項(xiàng)目里我一般提供兩層實(shí)現(xiàn)小的動(dòng)態(tài)模型先用字典數(shù)據(jù)量到了預(yù)警值再切換成動(dòng)態(tài)生成的強(qiáng)類型類。5.4 編輯校驗(yàn)里怎么拿同行其他列動(dòng)態(tài)行做校驗(yàn)有個(gè)天然難題編輯模板里DataContext雖然是行對(duì)象但你無法預(yù)知要校驗(yàn)?zāi)膸讉€(gè)字段。我的做法是提供一個(gè)Validate(string column, object? value)方法到DynamicRow上然后用附加行為攔截DataGrid.RowEditEnding或單元格的LostFocus事件。private void OnRowEditEnding(object? sender, DataGridRowEditEndingEventArgs e) { if (e.EditAction ! DataGridEditAction.Commit) return; var row e.Row.DataContext as DynamicRow; if (row null) return; var error row.ValidateAll(); if (!string.IsNullOrEmpty(error)) { e.Cancel true; MessageBox.Show(error); } }這樣校驗(yàn)邏輯集中在DynamicRow里ViewModel不需要知道UI細(xì)節(jié)也符合MVVM的邊界劃分。5.5 虛擬化與Column Span的關(guān)系如果用了動(dòng)態(tài)列又想開啟EnableColumnVirtualization要注意模板列的寬度和凍結(jié)列設(shè)置。列寬不固定的時(shí)候橫向虛擬化容易計(jì)算出錯(cuò)表現(xiàn)是滾動(dòng)到后面出現(xiàn)空白列。解決方法是統(tǒng)一給動(dòng)態(tài)列設(shè)置默認(rèn)寬度或者用DataGridLength.SizeToCells在列數(shù)少的時(shí)候使用。列很多且寬度不定時(shí)寧可關(guān)閉EnableColumnVirtualization保縱向虛擬化穩(wěn)定優(yōu)先。6. 和MVVM框架配合時(shí)的邊界控制6.1 DynamicRow繼承ObservableObject如果用CommunityToolkit.Mvvm直接讓DynamicRow繼承ObservableObject索引器里調(diào)用OnPropertyChanged就行。如果用Prism同理也可以繼承BindableBase。我建議不要把動(dòng)態(tài)行綁定到某個(gè)固定框架的內(nèi)部類型上而是自己寫一個(gè)極簡(jiǎn)的INPC實(shí)現(xiàn)避免框架升級(jí)帶來的遷移成本。CommunityToolkit.Mvvm的ObservableObject是可繼承的直接繼承即可不必重復(fù)造輪子。6.2 代碼后臺(tái)不是洪水猛獸MVVM社區(qū)里有一種極端傾向View的代碼后臺(tái)一行都不能寫。但DataGrid這種控件列集合本來就是UI層面的東西綁定不了就直接在后臺(tái)代碼里做轉(zhuǎn)換是正常且合理的。我在這套方案里附加屬性承載了后臺(tái)邏輯但從使用方的角度看XAML里只需要一行DataGrid ItemsSource{Binding RowsView} controls:DataGridColumnsBehavior.BindableColumns{Binding Columns} /業(yè)務(wù)代碼完全不用關(guān)心DataGrid.Columns怎么生成這就是MVVM的核心價(jià)值而不是代碼后臺(tái)零行數(shù)。6.3 列配置持久化動(dòng)態(tài)列還有一個(gè)隱藏需求用戶調(diào)好的列寬、順序、顯隱下次打開程序要還原。因?yàn)镃olumnMeta本身是普通數(shù)據(jù)對(duì)象序列化很方便public class ColumnLayoutItem { public string BindingPath { get; set; } public double Width { get; set; } public bool Visible { get; set; } public int DisplayIndex { get; set; } }保存時(shí)遍歷Columns集合寫入JSON或XML加載時(shí)在ViewModel里重建ColumnMeta集合。這里是真正的MVVM甜點(diǎn)區(qū)因?yàn)槟悴恍枰バ蛄谢疍ataGridColumn這種UI對(duì)象只需要存純數(shù)據(jù)。我實(shí)際項(xiàng)目里還加了一個(gè)列配置的右鍵菜單切換Visible屬性DataGrid的列就會(huì)即時(shí)顯隱這個(gè)聯(lián)動(dòng)也是通過ColumnMeta的PropertyChanged驅(qū)動(dòng)UI層實(shí)現(xiàn)的。6.4 給MVVM框架的命令傳參留個(gè)口子動(dòng)態(tài)列的按鈕列比如每一行的詳情按鈕需要綁定命令命令參數(shù)通常是當(dāng)前行對(duì)象。模板工廠里構(gòu)造按鈕時(shí)var button new FrameworkElementFactory(typeof(Button)); button.SetBinding(Button.CommandProperty, new Binding(DataContext.YourCommand) { RelativeSource new RelativeSource(RelativeSourceMode.FindAncestor, typeof(DataGrid), 1) }); button.SetBinding(Button.CommandParameterProperty, new Binding());或者更干凈的方式在ColumnMeta上掛一個(gè)Command參數(shù)讓Button綁定ColumnMeta.CommandCommandParameter綁定當(dāng)前行。綁定源用Sourcemeta即可。這樣按鈕命令也能保持在ViewModel層不會(huì)散落到UI事件里。這套方案用下來的一點(diǎn)體會(huì)動(dòng)態(tài)列在最開始看起來是個(gè)功能做完整套之后回頭看它其實(shí)是數(shù)據(jù)模型與UI生成策略的適配問題。把列這個(gè)概念從DataGridColumn抽成ColumnMeta把行從固定實(shí)體類改成DynamicRow剩下的事情就是翻譯和同步。我這個(gè)方案里用了附加屬性、模板工廠、索引器綁定沒有用到任何黑魔法所有環(huán)節(jié)都可以在調(diào)試器里一步步追蹤。如果你手頭只是幾十行數(shù)據(jù)的臨時(shí)報(bào)表直接用DataTable亂搞也行省事。但只要摻進(jìn)編輯器可控、列顯隱可配置、要接后端序列化、要長(zhǎng)期維護(hù)這幾個(gè)詞我建議趁早切到列元數(shù)據(jù)驅(qū)動(dòng)。前期多寫一個(gè)ColumnMeta的代價(jià)很低后面省下的補(bǔ)丁時(shí)間可不止翻倍。最后再分享一個(gè)小技巧所有動(dòng)態(tài)列模板統(tǒng)一走一個(gè)資源字典的靜態(tài)類不要在自己寫的每個(gè)頁面里各建一套模板否則后期維護(hù)每列樣式時(shí)你會(huì)想罵人。本文還有配套的精品資源點(diǎn)擊獲取