據(jù)綁定、ViewModel分層與跨平臺工程實踐)
1. MVVM到底在解決什么問題1.1 從MVC說起MVVM的出現(xiàn)背景早些年寫界面程序大家普遍用的是MVCModel-View-Controller這套模式本身沒毛病但落到實際的桌面客戶端開發(fā)里越寫越別扭。View和Controller的邊界太模糊了寫著寫著Controller就把View的控件拿過來直接操作View里也塞滿了業(yè)務判斷Model被兩頭拉扯。項目小的時候還能湊合一旦業(yè)務復雜起來改一個需求要連帶著翻好幾個文件單元測試基本沒法寫因為邏輯全和UI控件糾纏在一起根本沒法脫離界面去跑。MVVMModel-View-ViewModel就是在這樣的背景下被微軟的John Gossman提出來的最初是為了配合WPF的數(shù)據(jù)綁定能力。它的核心思路是把界面View、數(shù)據(jù)Model和中間的狀態(tài)與行為ViewModel徹底拆開View只管顯示和收集用戶輸入ViewModel負責把Model轉(zhuǎn)換成View可以直接消費的狀態(tài)并且通過數(shù)據(jù)綁定這個“管道”讓兩端自動同步。說白了就是UI不再直接操作數(shù)據(jù)數(shù)據(jù)也不再關心自己是怎么被畫出來的。1.2 MVVM的三層職責劃分很多剛接觸MVVM的人會被三個名詞繞暈我用大白話拆一遍。Model層負責業(yè)務數(shù)據(jù)和數(shù)據(jù)訪問。它就是你的實體類、數(shù)據(jù)庫訪問、網(wǎng)絡請求這些“不穿衣服”的東西完全不認識Button、TextBox長什么樣。View層就是界面本身XAML、XML或者Qt里的QML凡是用戶看得見摸得著的都屬于這一層。ViewModel層是整個架構(gòu)的樞紐它把Model的數(shù)據(jù)“翻譯”成View能綁定的屬性同時把View上的用戶操作接收過來轉(zhuǎn)化成對Model的調(diào)用。這三層里View和ViewModel之間是通過數(shù)據(jù)綁定和命令關聯(lián)的View完全不知道Model的存在ViewModel也不知道View的存在兩邊都只跟抽象約定打交道。這帶來的直接好處是什么是測試。你可以在不啟動界面的情況下new一個ViewModel給它喂數(shù)據(jù)驗證它的狀態(tài)和輸出對不對。對做客戶端的人來說這種“能測UI邏輯”的能力在以前是想都不敢想的。1.3 一條數(shù)據(jù)流的完整生命周期理解MVVM的核心是理解數(shù)據(jù)在三條鏈路里怎么流動。第一條是“Model到View”的展示鏈路Model數(shù)據(jù)被加載后賦值給ViewModel里的屬性屬性通過通知機制告訴View“我變了”View自動刷新。第二條是“View到Model”的操作鏈路用戶點擊按鈕View把點擊事件轉(zhuǎn)交給ViewModel里的命令命令執(zhí)行業(yè)務邏輯并調(diào)用Model的方法。第三條是“View到ViewModel再到View”的聯(lián)動鏈路用戶在界面上輸入文字通過雙向綁定直接寫回ViewModel的屬性屬性一變其他依賴這個屬性的UI部分也跟著更新。這三條鏈路全部由綁定機制驅(qū)動你在代碼里幾乎看不到“textBox1.Text xxx”這種直接賦值。這也是MVVM被詬病“學習曲線陡峭”的原因——很多人第一次接觸時覺得小題大做等真正把這條鏈路理順之后才會發(fā)現(xiàn)代碼組織方式完全上了一個臺階。2. MVVM的核心機制數(shù)據(jù)綁定與命令2.1 數(shù)據(jù)綁定UI和數(shù)據(jù)的單向/雙向通道數(shù)據(jù)綁定是MVVM的命根子沒有它MVVM就是空中樓閣。綁定分為單向和雙向單向綁定是指數(shù)據(jù)源變了UI自動跟著變適合展示類信息雙向綁定是指UI變了寫回數(shù)據(jù)源數(shù)據(jù)源變了又刷新UI適合輸入類控件。以WPF為例一個輸入框的綁定長這樣TextBox Text{Binding UserName, UpdateSourceTriggerPropertyChanged} /屬性名后面的UpdateSourceTrigger值得單獨說。默認情況下TextBox的綁定在失去焦點時才把值寫回源但用戶更習慣邊輸入邊觸發(fā)校驗這時候把觸發(fā)時機改成PropertyChanged每次按鍵都會同步到ViewModel。這個細節(jié)在實際體驗上差別巨大很多人說MVVM輸入卡頓或校驗不及時一半以上是栽在這里。綁定還有一個方向問題——你總得告訴框架數(shù)據(jù)往哪流ModeOneWay表示只展示不寫回ModeTwoWay表示雙向ModeOneTime表示只在加載時綁定一次。做大數(shù)據(jù)量列表展示時把能改OneTime的地方都改成OneTime渲染性能會有肉眼可見的提升這是優(yōu)化老手的基本操作。2.2 命令系統(tǒng)把事件變成可測試的邏輯數(shù)據(jù)綁定解決了“屬性怎么同步”但用戶的“動作”怎么辦按鈕點擊、右鍵菜單、拖拽操作這些都是事件傳統(tǒng)寫法是直接在事件處理器里寫邏輯。MVVM的做法是引入命令Command把“用戶想做什么”抽象成一個對象。命令接口一般就三個成員CanExecute這個動作現(xiàn)在能不能執(zhí)行、Execute執(zhí)行這個動作、以及CanExecuteChanged通知。界面上按鈕綁定了命令之后按鈕的可用狀態(tài)完全由命令里的CanExecute決定業(yè)務上不用再手動去搞button.Enabled true這種代碼。這里我想多說一句命令的CanExecute是一個非常容易被低估的設計。我見過很多項目把按鈕置灰的邏輯散落在各處比如“沒有選中項時刪除按鈕不可用”用代碼判斷往往要寫好幾個地方而且容易漏。用命令之后只需要在屬性變化時觸發(fā)CanExecuteChanged讓按鈕自己重新問一次“我能不能點”整個狀態(tài)管理就收斂到了命令內(nèi)部邏輯清晰還不容易出bug。2.3 INotifyPropertyChanged屬性通知的底層原理MVVM里有一個繞不開的接口叫INotifyPropertyChanged它做的事情很簡單屬性值變了就對外廣播一個“某某屬性變了”的事件。綁定引擎收到這個事件后去查找哪些UI元素依賴這個屬性然后更新它們。問題在于這個接口如果手動實現(xiàn)代碼非常啰嗦private string _userName; public string UserName { get { return _userName; } set { if (_userName ! value) { _userName value; OnPropertyChanged(nameof(UserName)); } } }每個屬性都寫一遍一個ViewModel幾十個屬性光樣板代碼就能把人寫吐。所以實際項目中幾乎都會封裝一個ViewModel基類用SetProperty方法把賦值和通知合并在一起public class ViewModelBase : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected bool SetPropertyT(ref T field, T value, [CallerMemberName] string propertyName null) { if (EqualityComparerT.Default.Equals(field, value)) return false; field value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); return true; } }有了這個基類屬性定義就變成一行private string _userName; public string UserName { get _userName; set SetProperty(ref _userName, value); }注意我用了CallerMemberName編譯器會自動把調(diào)用處的屬性名填進來這樣即使屬性后面改了名字通知的屬性名也不會因為手打字符串而出錯。這種小細節(jié)在重構(gòu)頻繁的項目里能省下不少排查時間。3. MVVM落地實操從零搭建一個完整的MVVM項目3.1 項目結(jié)構(gòu)規(guī)劃與分層空談概念沒有意義我直接用一個實際場景演示怎么從零搭一個MVVM項目。假設我們要做一個簡單的用戶登錄窗口帶用戶名輸入、密碼輸入、登錄按鈕和狀態(tài)提示。項目結(jié)構(gòu)我建議這樣分src/ ├── Models/ │ └── User.cs ├── ViewModels/ │ ├── ViewModelBase.cs │ ├── RelayCommand.cs │ └── LoginViewModel.cs ├── Views/ │ └── LoginView.xaml └── Services/ └── IAuthService.cs很多人第一步就會糾結(jié)ViewModel放哪個文件夾Service要不要單獨建一層我的建議是小項目別過度設計四五個文件夾足夠。Models放實體ViewModels放所有VMViews放所有窗口和控件Services放接口和實現(xiàn)。等業(yè)務量大到某個文件夾超過十幾個文件時再按模塊拆分也不遲。3.2 ViewModel基類與命令基類的實現(xiàn)前面已經(jīng)寫了ViewModelBase現(xiàn)在補上命令基類。這里說的RelayCommand是MVVM里最通用的命令實現(xiàn)本質(zhì)就是把一個委托包裝成命令public class RelayCommand : ICommand { private readonly Action _execute; private readonly Funcbool _canExecute; public RelayCommand(Action execute, Funcbool canExecute null) { _execute execute; _canExecute canExecute; } public bool CanExecute(object parameter) _canExecute null || _canExecute(); public void Execute(object parameter) _execute(); public event EventHandler CanExecuteChanged { add { CommandManager.RequerySuggested value; } remove { CommandManager.RequerySuggested - value; } } }這個實現(xiàn)里有幾個點值得解釋。CanExecuteChanged事件我直接掛到了WPF的CommandManager.RequerySuggested上這個事件會在UI交互比如點擊、焦點變化時自動觸發(fā)讓綁定到命令的按鈕機制自己去刷新可用狀態(tài)。如果你想手動控制刷新時機也可以改成普通事件然后在合適的時機調(diào)用CommandManager.InvalidateRequerySuggested()強制刷新。帶泛型參數(shù)的命令版本也值得準備一個因為很多操作需要傳入?yún)?shù)比如列表項操作。寫法差不多把Action換成ActionTFuncbool換成FuncT, bool就行。我一般在項目里固定放三個命令類無參、帶參、以及帶異步支持的AsyncRelayCommand后面那個在講異步時再展開。3.3 一個登錄頁面的完整MVVM實現(xiàn)先定義Model。用戶實體很簡單就是登錄成功后要展示的用戶名public class User { public string UserName { get; set; } public string DisplayName { get; set; } }再定義一個認證服務接口讓ViewModel依賴抽象而不是具體實現(xiàn)public interface IAuthService { TaskUser LoginAsync(string userName, string password); }接著是核心的LoginViewModelpublic class LoginViewModel : ViewModelBase { private readonly IAuthService _authService; private string _userName; private string _password; private string _statusMessage; private bool _isBusy; public string UserName { get _userName; set { if (SetProperty(ref _userName, value)) LoginCommand?.RaiseCanExecuteChanged(); } } public string Password { get _password; set { if (SetProperty(ref _password, value)) LoginCommand?.RaiseCanExecuteChanged(); } } public string StatusMessage { get _statusMessage; set SetProperty(ref _statusMessage, value); } public bool IsBusy { get _isBusy; set SetProperty(ref _isBusy, value); } public RelayCommand LoginCommand { get; } public LoginViewModel(IAuthService authService) { _authService authService; LoginCommand new RelayCommand(ExecuteLogin, CanExecuteLogin); } private bool CanExecuteLogin() { return !string.IsNullOrWhiteSpace(UserName) !string.IsNullOrEmpty(Password) !IsBusy; } private async void ExecuteLogin() { IsBusy true; StatusMessage 正在登錄...; try { var user await _authService.LoginAsync(UserName, Password); StatusMessage $歡迎你{user.DisplayName}; } catch (Exception ex) { StatusMessage $登錄失敗{ex.Message}; } finally { IsBusy false; LoginCommand.RaiseCanExecuteChanged(); } } }這個ViewModel有幾個地方是經(jīng)驗沉淀出來的。第一UserName和Password的setter里在值變化后調(diào)用了LoginCommand.RaiseCanExecuteChanged()保證輸入內(nèi)容變化時按鈕的可用狀態(tài)立刻刷新。第二用IsBusy在登錄期間鎖住按鈕防止用戶反復提交。第三ExecuteLogin里把異常捕獲并轉(zhuǎn)成用戶可讀的狀態(tài)消息而不是讓異常直接冒泡到UI線程導致崩潰。對應的View綁定就非常直白TextBox Text{Binding UserName, UpdateSourceTriggerPropertyChanged} / PasswordBox PasswordChangedPasswordBox_PasswordChanged / Button Content登錄 Command{Binding LoginCommand} / TextBlock Text{Binding StatusMessage} /注意密碼框有一點繞WPF的PasswordBox出于安全考慮不提供綁定依賴屬性所以要手動在后臺代碼里把密碼轉(zhuǎn)發(fā)給ViewModel。這算MVVM里為數(shù)不多“需要破例”的地方我一般的做法是在PasswordChanged事件里寫一行((LoginViewModel)DataContext).Password passwordBox.Password;這種例外是框架限制導致的不必為了教條而強行不用代碼后臺。3.4 服務定位與依賴注入的引入時機在上面的例子里LoginViewModel的構(gòu)造函數(shù)接收了一個IAuthService參數(shù)。那這個參數(shù)從哪來這就是依賴注入DI要解決的問題。最簡單的做法是不用任何框架在創(chuàng)建ViewModel的地方手動newvar vm new LoginViewModel(new HttpAuthService());小項目這么做沒問題但服務一多手動管理依賴就會亂。WPF社區(qū)里常用的做法是引入一個輕量級DI容器比如Microsoft.Extensions.DependencyInjectionApp啟動時注冊所有服務ViewModel通過構(gòu)造函數(shù)自動解析。這樣做的價值在項目中期才體現(xiàn)出來——你想給某個服務加緩存實現(xiàn)時只改注冊代碼所有使用方完全不用動。依賴注入的引入時機我建議看項目體量如果只有兩三個ViewModel手動裝配完全夠用一旦超過五六個或者服務之間有互相依賴就越早引入越好。別在項目初期糾結(jié)用什么高級框架先把分層做好后面替換成本很低。4. 主流平臺MVVM實踐對照4.1 WPF/WinForm微軟生態(tài)的MVVM玩法WPF是MVVM的原生主場。它從誕生起就內(nèi)置了完整的數(shù)據(jù)綁定、命令、模板、樣式系統(tǒng)本質(zhì)上就是為MVVM準備的。在WPF里做MVVM你只需要關注ViewModel怎么寫View的綁定在XAML里完成框架替你處理了絕大部分苦力工作。WinForm的情況比較特殊它是控件驅(qū)動的舊框架沒有原生數(shù)據(jù)綁定管道。社區(qū)里常見的做法是引入第三方MVVM框架比如之前我接觸過的一些團隊在WinForm上用MVVMLight的移植版或者CommunityToolkit.Mvvm通過給控件手動掛事件、在事件處理器里轉(zhuǎn)發(fā)給命令來實現(xiàn)。效果打個折扣但至少邏輯能分離。這里分享一個我對WinForm項目的判斷如果項目是從零開始的新的桌面項目優(yōu)先考慮WPF或者后來興起的跨平臺UI方案。如果必須基于老WinForm代碼繼續(xù)迭代硬套MVVM不如做“分步改造”——先把業(yè)務邏輯從窗體代碼里抽到獨立的服務類把窗體的數(shù)據(jù)訪問改成屬性驅(qū)動再逐步引入綁定和命令。一口氣重構(gòu)在WinForm里風險太高。4.2 Android官方推薦的MVVM組合Android從2017年左右開始官方推薦MVVM架構(gòu)Jetpack組件里的ViewModel、LiveData、DataBinding以及后來的StateFlow組合起來就是一套非常完整的MVVM實踐。Android里的ViewModel和桌面端的ViewModel在設計上有一些差異。Android的ViewModel是生命周期感知組件它在配置變更比如旋轉(zhuǎn)屏幕時不會被銷毀數(shù)據(jù)因此得以存活這是為移動端場景專門設計的生命周期機制。LiveData或者StateFlow充當了數(shù)據(jù)綁定的角色——ViewModel暴露可觀察的數(shù)據(jù)界面訂閱這些數(shù)據(jù)并更新UI。class LoginViewModel(private val authRepository: AuthRepository) : ViewModel() { private val _userName MutableStateFlow() val userName: StateFlowString _userName.asStateFlow() private val _uiState MutableStateFlowLoginUiState(LoginUiState.Idle) val uiState: StateFlowLoginUiState _uiState.asStateFlow() fun onUserNameChanged(input: String) { _userName.value input } fun login() { viewModelScope.launch { _uiState.value LoginUiState.Loading val result authRepository.login(_userName.value, _password.value) _uiState.value LoginUiState.Success(result) } } }Android MVVM里我特別想提醒的是“狀態(tài)提升”State Hoisting思路UI狀態(tài)被集中封裝成不可變的UiState對象界面根據(jù)狀態(tài)決定顯示什么而不是每個屬性單獨暴露。這樣界面渲染只有一條決策鏈狀態(tài)越多優(yōu)勢越明顯。4.3 QtC世界的MVVM變體Qt的推薦做法里很多人習慣用Model/View框架但它和MVVM并不完全是一回事。Qt社區(qū)里最貼近MVVM的是QML加Qt Quick這套組合QML對應ViewC類通過繼承QObject并暴露屬性給QML訪問天然支持屬性綁定這一層就相當于ViewModel。Qt里做MVVM的核心機制是信號槽和屬性綁定。C端的類通過Q_PROPERTY宏暴露可綁定的屬性屬性變化時發(fā)出信號QML端用onXxxChanged或者在布局里直接綁定到屬性名改動一處界面自動聯(lián)動class LoginViewModel : public QObject { Q_OBJECT Q_PROPERTY(QString userName READ userName WRITE setUserName NOTIFY userNameChanged) Q_PROPERTY(QString statusMessage READ statusMessage WRITE setStatusMessage NOTIFY statusMessageChanged) public: Q_INVOKABLE void login(); signals: void userNameChanged(); void statusMessageChanged(); };Qt MVVM實操中最大的坑是數(shù)據(jù)同步線程模型。C里耗時操作跑在工作線程完成后要跨線程更新屬性稍不小心UI線程就被卡頓甚至崩潰。我建議所有耗時操作通過信號跨線程返回再用QMetaObject::invokeMethod把UI更新調(diào)度回主線程別在子線程里直接改屬性。4.4 不同平臺MVVM實現(xiàn)對比表平臺View層ViewModel載體綁定機制典型坑點WPFXAMLINotifyPropertyChanged依賴屬性綁定綁定失效時不報錯靜默WinForm窗體控件普通類事件轉(zhuǎn)發(fā)框架不原生支持綁定AndroidCompose/XMLJetpack ViewModelLiveData/StateFlow生命周期泄漏QtQMLQObject派生類屬性系統(tǒng)信號槽跨線程更新UI這張表想表達的核心信息是MVVM是思想而不是具體API它在不同平臺的實現(xiàn)差異很大但底層的“數(shù)據(jù)驅(qū)動UI、邏輯可測試”這個內(nèi)核是通用的。你在一套平臺上真正理解了MVVM換平臺時只是重新學習綁定語法而已。5. MVVM常見問題與排查技巧實錄5.1 綁定不生效八成是這幾個原因做MVVM一定會遇到“界面死活不更新”的情況。根據(jù)我的經(jīng)驗90%的綁定不生效可以歸因到以下幾類。一是屬性沒有通知。ViewModel的屬性本身變化了但沒有觸發(fā)PropertyChanged事件綁定引擎不知道數(shù)據(jù)變了。檢查方法是看屬性定義里是否用了SetProperty如果你的代碼是_userName value然后沒有調(diào)用通知那頁面不可能刷新。二是通知了錯誤的屬性名。當視圖綁定了UserName但通知寫成了Username少一個N綁定引擎找不到匹配靜默失敗。三是DataContext沒有設置。ViewModel沒有掛到界面的數(shù)據(jù)上下文上綁定找不到來源這種情況在控制臺會有綁定錯誤輸出但很多人忽略它。四是綁定的屬性路徑寫錯比如控件綁到了ViewModel的一個子對象的屬性上但子對象是null也會導致沒有反應。排查綁定問題的推薦工具是調(diào)試時看一眼輸出窗口。WPF的綁定錯誤會打印到調(diào)試輸出里格式大致是BindingExpression path error: Xxx property not found看到這個信息基本就能定位。我在編碼時習慣先關掉“僅我的代碼”讓綁定錯誤全部顯示出來不然有些錯誤被吞掉排查效率非常低。5.2 ViewModel內(nèi)存泄漏的排查與規(guī)避MVVM架構(gòu)里有一個企業(yè)級項目一定會踩的坑ViewModel和View互相引用導致對象無法被垃圾回收。典型的場景是這樣的View構(gòu)造ViewModel并為其掛上事件訂閱比如訂閱了某個全局消息或服務的通知事件但View關閉時忘了取消訂閱。由于事件發(fā)布者持有訂閱者引用你的ViewModel甚至整個View都不會被釋放內(nèi)存占用越來越高。我在排查這類泄漏時的經(jīng)驗是關掉界面的生命周期里主動調(diào)用ViewModel的Cleanup方法把事件訂閱全部解除。另一個常見泄漏源頭是命令綁定導致的事件持有。某些框架里按鈕的Command綁定會讓我方持有View如果我在View的代碼里手動訂閱了CommandManager的RequerySuggested而不取消也會形成引用鏈。我的經(jīng)驗是ViewModel里的事件盡量用弱事件模式WeakEvent或者統(tǒng)一在Cleanup里退訂雙保險。5.3 過度MVVM化架構(gòu)潔癖的成本MVVM是一個工具不是信仰。我在項目里見過最離譜的做法是連一個簡單的提示框彈窗都要走命令加服務一個只讀的Label顯示固定文本也要建一個ViewModel屬性一個窗口里十幾個控件每個都要綁定一個命令。這種過度設計讓簡單的功能寫起來復雜了三倍團隊成員每次改需求都要在五六個文件之間來回跳。有一個判斷標準可以幫你拿捏分寸如果一個操作只是純粹的UI行為比如調(diào)整窗口大小、收起展開某個面板不涉及業(yè)務邏輯和數(shù)據(jù)處理那完全可以直接寫事件處理沒必要套命令。如果一個屬性只是界面內(nèi)部狀態(tài)、不需要持久化也不需要被其他邏輯消費那也沒必要放進ViewModel。MVVM的價值在于讓業(yè)務邏輯變得可測試和可維護而不是讓所有UI代碼都禁止出現(xiàn)在View層。5.4 異步操作的競態(tài)問題處理MVVM里大量涉及異步操作比如登錄、加載列表、上傳文件。一個隱蔽的問題叫“競態(tài)條件”用戶先后觸發(fā)了兩次異步操作第一次的結(jié)果還沒回來第二次的結(jié)果先到了界面顯示的數(shù)據(jù)是新舊混雜的。標準做法是引入“請求序號”機制。每次發(fā)起異步操作時遞增一個計數(shù)器異步結(jié)果回來時檢查序號是否還是自己發(fā)起操作時的序號如果不是就丟棄結(jié)果。這種方法在WPF和Android里都適用代碼也不復雜private int _requestId; private async void ExecuteLoad() { var currentId _requestId; IsBusy true; try { var result await _service.LoadAsync(); if (currentId ! _requestId) return; // 過期結(jié)果直接丟棄 Items result; } finally { IsBusy false; } }這個問題在舊的項目里幾乎沒人處理因為傳統(tǒng)事件驅(qū)動開發(fā)中異步回調(diào)也是同樣的問題但MVVM的封裝讓異步操作變得更多更密集所以更值得重視。特別是做移動端或者數(shù)據(jù)刷新頻繁的桌面應用競態(tài)處理一定要做到位。6. 踩坑三四年后我對MVVM的個人體會6.1 什么時候不該用MVVM聊了這么多MVVM的好處我也想潑點冷水。不是所有項目都適合上MVVM。如果你的項目只是一個幾千行代碼的小工具界面總共兩三個窗口業(yè)務邏輯簡單到一眼看穿強行引入MVVM只會增加代碼量和理解成本反而拖慢開發(fā)速度。我的判斷標準很簡單如果這個項目的UI邏輯需要寫單元測試或者未來大概率會不斷擴充業(yè)務比如從單窗口長成多模塊或者團隊不止一個人同時改界面和邏輯那MVVM能給你帶來明顯收益。如果只是個人寫個內(nèi)部工具、生命周期只有幾個月那保持輕量就好。架構(gòu)是為業(yè)務服務的不是為了好看。6.2 團隊協(xié)作中MVVM的約定大于配置MVVM沒有統(tǒng)一的官方標準不同人寫出來的MVVM風格差異可以非常大。有人喜歡把所有邏輯塞進ViewModel有人習慣在ViewModel里再拆業(yè)務服務層有人命令全部用AsyncRelayCommand有人只用普通RelayCommand配合async void。團隊協(xié)作時這些問題不統(tǒng)一代碼review成本會直線上升。我的建議是項目一開始就定一份簡單的MVVM約定文檔內(nèi)容包括ViewModel命名規(guī)則后綴統(tǒng)一用ViewModel、命令統(tǒng)一在構(gòu)造器里初始化、所有耗時操作必須走異步命令不允許裸用async void、服務接口一律放Services層。這些約定寫清楚之后新人上手成本會低很多代碼風格也不會五花八門。6.3 最后分享一個分組校驗的小技巧MVVM里表單校驗是個繞不開的需求。我做過一個還算好用的方案ViewModel基類里維護一個字典記錄每個屬性的錯誤信息校驗時分組執(zhí)行驗證規(guī)則把錯誤消息匯總到界面統(tǒng)一展示。public class ValidationViewModelBase : ViewModelBase { private readonly Dictionarystring, string _errors new(); public bool HasErrors _errors.Count 0; protected void ValidateProperty(string propertyName, Funcbool rule, string errorMessage) { if (rule()) { _errors.Remove(propertyName); } else { _errors[propertyName] errorMessage; } } public bool ValidateAll() !_errors.Any(); }界面只需要在按鈕命令執(zhí)行前先調(diào)ValidateAll()不符合就提示錯誤并終止操作。這套方案比挨個控件校驗要集中、可控而且能被單元測試覆蓋。團隊里后來的人加新校驗時只需要在ViewModel里多寫一行規(guī)則代碼不用去動界面這也是MVVM帶來的日常便利。MVVM這條路我走了好幾年從最開始覺得它純粹是增加工作量到后來在大型項目里嘗到甜頭再到現(xiàn)在能比較清晰地判斷什么場景該用什么程度的架構(gòu)最大的體會是架構(gòu)模式的真正價值不是讓代碼“看起來高級”而是讓未來的自己和同事改代碼時少一點提心吊膽。如果你正在一個邏輯糾纏不清的界面項目里掙扎不妨從拆一個最簡單的窗口開始用數(shù)據(jù)綁定的方式把邏輯挪進ViewModel里試試。那一步邁出去后面的路會順很多。 從MVC到MVVM：數(shù)據(jù)綁定、ViewModel分層與跨平臺工程實踐
1. MVVM到底在解決什么問題1.1 從MVC說起MVVM的出現(xiàn)背景早些年寫界面程序大家普遍用的是MVCModel-View-Controller這套模式本身沒毛病但落到實際的桌面客戶端開發(fā)里越寫越別扭。View和Controller的邊界太模糊了寫著寫著Controller就把View的控件拿過來直接操作View里也塞滿了業(yè)務判斷Model被兩頭拉扯。項目小的時候還能湊合一旦業(yè)務復雜起來改一個需求要連帶著翻好幾個文件單元測試基本沒法寫因為邏輯全和UI控件糾纏在一起根本沒法脫離界面去跑。MVVMModel-View-ViewModel就是在這樣的背景下被微軟的John Gossman提出來的最初是為了配合WPF的數(shù)據(jù)綁定能力。它的核心思路是把界面View、數(shù)據(jù)Model和中間的狀態(tài)與行為ViewModel徹底拆開View只管顯示和收集用戶輸入ViewModel負責把Model轉(zhuǎn)換成View可以直接消費的狀態(tài)并且通過數(shù)據(jù)綁定這個“管道”讓兩端自動同步。說白了就是UI不再直接操作數(shù)據(jù)數(shù)據(jù)也不再關心自己是怎么被畫出來的。1.2 MVVM的三層職責劃分很多剛接觸MVVM的人會被三個名詞繞暈我用大白話拆一遍。Model層負責業(yè)務數(shù)據(jù)和數(shù)據(jù)訪問。它就是你的實體類、數(shù)據(jù)庫訪問、網(wǎng)絡請求這些“不穿衣服”的東西完全不認識Button、TextBox長什么樣。View層就是界面本身XAML、XML或者Qt里的QML凡是用戶看得見摸得著的都屬于這一層。ViewModel層是整個架構(gòu)的樞紐它把Model的數(shù)據(jù)“翻譯”成View能綁定的屬性同時把View上的用戶操作接收過來轉(zhuǎn)化成對Model的調(diào)用。這三層里View和ViewModel之間是通過數(shù)據(jù)綁定和命令關聯(lián)的View完全不知道Model的存在ViewModel也不知道View的存在兩邊都只跟抽象約定打交道。這帶來的直接好處是什么是測試。你可以在不啟動界面的情況下new一個ViewModel給它喂數(shù)據(jù)驗證它的狀態(tài)和輸出對不對。對做客戶端的人來說這種“能測UI邏輯”的能力在以前是想都不敢想的。1.3 一條數(shù)據(jù)流的完整生命周期理解MVVM的核心是理解數(shù)據(jù)在三條鏈路里怎么流動。第一條是“Model到View”的展示鏈路Model數(shù)據(jù)被加載后賦值給ViewModel里的屬性屬性通過通知機制告訴View“我變了”View自動刷新。第二條是“View到Model”的操作鏈路用戶點擊按鈕View把點擊事件轉(zhuǎn)交給ViewModel里的命令命令執(zhí)行業(yè)務邏輯并調(diào)用Model的方法。第三條是“View到ViewModel再到View”的聯(lián)動鏈路用戶在界面上輸入文字通過雙向綁定直接寫回ViewModel的屬性屬性一變其他依賴這個屬性的UI部分也跟著更新。這三條鏈路全部由綁定機制驅(qū)動你在代碼里幾乎看不到“textBox1.Text xxx”這種直接賦值。這也是MVVM被詬病“學習曲線陡峭”的原因——很多人第一次接觸時覺得小題大做等真正把這條鏈路理順之后才會發(fā)現(xiàn)代碼組織方式完全上了一個臺階。2. MVVM的核心機制數(shù)據(jù)綁定與命令2.1 數(shù)據(jù)綁定UI和數(shù)據(jù)的單向/雙向通道數(shù)據(jù)綁定是MVVM的命根子沒有它MVVM就是空中樓閣。綁定分為單向和雙向單向綁定是指數(shù)據(jù)源變了UI自動跟著變適合展示類信息雙向綁定是指UI變了寫回數(shù)據(jù)源數(shù)據(jù)源變了又刷新UI適合輸入類控件。以WPF為例一個輸入框的綁定長這樣TextBox Text{Binding UserName, UpdateSourceTriggerPropertyChanged} /屬性名后面的UpdateSourceTrigger值得單獨說。默認情況下TextBox的綁定在失去焦點時才把值寫回源但用戶更習慣邊輸入邊觸發(fā)校驗這時候把觸發(fā)時機改成PropertyChanged每次按鍵都會同步到ViewModel。這個細節(jié)在實際體驗上差別巨大很多人說MVVM輸入卡頓或校驗不及時一半以上是栽在這里。綁定還有一個方向問題——你總得告訴框架數(shù)據(jù)往哪流ModeOneWay表示只展示不寫回ModeTwoWay表示雙向ModeOneTime表示只在加載時綁定一次。做大數(shù)據(jù)量列表展示時把能改OneTime的地方都改成OneTime渲染性能會有肉眼可見的提升這是優(yōu)化老手的基本操作。2.2 命令系統(tǒng)把事件變成可測試的邏輯數(shù)據(jù)綁定解決了“屬性怎么同步”但用戶的“動作”怎么辦按鈕點擊、右鍵菜單、拖拽操作這些都是事件傳統(tǒng)寫法是直接在事件處理器里寫邏輯。MVVM的做法是引入命令Command把“用戶想做什么”抽象成一個對象。命令接口一般就三個成員CanExecute這個動作現(xiàn)在能不能執(zhí)行、Execute執(zhí)行這個動作、以及CanExecuteChanged通知。界面上按鈕綁定了命令之后按鈕的可用狀態(tài)完全由命令里的CanExecute決定業(yè)務上不用再手動去搞button.Enabled true這種代碼。這里我想多說一句命令的CanExecute是一個非常容易被低估的設計。我見過很多項目把按鈕置灰的邏輯散落在各處比如“沒有選中項時刪除按鈕不可用”用代碼判斷往往要寫好幾個地方而且容易漏。用命令之后只需要在屬性變化時觸發(fā)CanExecuteChanged讓按鈕自己重新問一次“我能不能點”整個狀態(tài)管理就收斂到了命令內(nèi)部邏輯清晰還不容易出bug。2.3 INotifyPropertyChanged屬性通知的底層原理MVVM里有一個繞不開的接口叫INotifyPropertyChanged它做的事情很簡單屬性值變了就對外廣播一個“某某屬性變了”的事件。綁定引擎收到這個事件后去查找哪些UI元素依賴這個屬性然后更新它們。問題在于這個接口如果手動實現(xiàn)代碼非常啰嗦private string _userName; public string UserName { get { return _userName; } set { if (_userName ! value) { _userName value; OnPropertyChanged(nameof(UserName)); } } }每個屬性都寫一遍一個ViewModel幾十個屬性光樣板代碼就能把人寫吐。所以實際項目中幾乎都會封裝一個ViewModel基類用SetProperty方法把賦值和通知合并在一起public class ViewModelBase : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected bool SetPropertyT(ref T field, T value, [CallerMemberName] string propertyName null) { if (EqualityComparerT.Default.Equals(field, value)) return false; field value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); return true; } }有了這個基類屬性定義就變成一行private string _userName; public string UserName { get _userName; set SetProperty(ref _userName, value); }注意我用了CallerMemberName編譯器會自動把調(diào)用處的屬性名填進來這樣即使屬性后面改了名字通知的屬性名也不會因為手打字符串而出錯。這種小細節(jié)在重構(gòu)頻繁的項目里能省下不少排查時間。3. MVVM落地實操從零搭建一個完整的MVVM項目3.1 項目結(jié)構(gòu)規(guī)劃與分層空談概念沒有意義我直接用一個實際場景演示怎么從零搭一個MVVM項目。假設我們要做一個簡單的用戶登錄窗口帶用戶名輸入、密碼輸入、登錄按鈕和狀態(tài)提示。項目結(jié)構(gòu)我建議這樣分src/ ├── Models/ │ └── User.cs ├── ViewModels/ │ ├── ViewModelBase.cs │ ├── RelayCommand.cs │ └── LoginViewModel.cs ├── Views/ │ └── LoginView.xaml └── Services/ └── IAuthService.cs很多人第一步就會糾結(jié)ViewModel放哪個文件夾Service要不要單獨建一層我的建議是小項目別過度設計四五個文件夾足夠。Models放實體ViewModels放所有VMViews放所有窗口和控件Services放接口和實現(xiàn)。等業(yè)務量大到某個文件夾超過十幾個文件時再按模塊拆分也不遲。3.2 ViewModel基類與命令基類的實現(xiàn)前面已經(jīng)寫了ViewModelBase現(xiàn)在補上命令基類。這里說的RelayCommand是MVVM里最通用的命令實現(xiàn)本質(zhì)就是把一個委托包裝成命令public class RelayCommand : ICommand { private readonly Action _execute; private readonly Funcbool _canExecute; public RelayCommand(Action execute, Funcbool canExecute null) { _execute execute; _canExecute canExecute; } public bool CanExecute(object parameter) _canExecute null || _canExecute(); public void Execute(object parameter) _execute(); public event EventHandler CanExecuteChanged { add { CommandManager.RequerySuggested value; } remove { CommandManager.RequerySuggested - value; } } }這個實現(xiàn)里有幾個點值得解釋。CanExecuteChanged事件我直接掛到了WPF的CommandManager.RequerySuggested上這個事件會在UI交互比如點擊、焦點變化時自動觸發(fā)讓綁定到命令的按鈕機制自己去刷新可用狀態(tài)。如果你想手動控制刷新時機也可以改成普通事件然后在合適的時機調(diào)用CommandManager.InvalidateRequerySuggested()強制刷新。帶泛型參數(shù)的命令版本也值得準備一個因為很多操作需要傳入?yún)?shù)比如列表項操作。寫法差不多把Action換成ActionTFuncbool換成FuncT, bool就行。我一般在項目里固定放三個命令類無參、帶參、以及帶異步支持的AsyncRelayCommand后面那個在講異步時再展開。3.3 一個登錄頁面的完整MVVM實現(xiàn)先定義Model。用戶實體很簡單就是登錄成功后要展示的用戶名public class User { public string UserName { get; set; } public string DisplayName { get; set; } }再定義一個認證服務接口讓ViewModel依賴抽象而不是具體實現(xiàn)public interface IAuthService { TaskUser LoginAsync(string userName, string password); }接著是核心的LoginViewModelpublic class LoginViewModel : ViewModelBase { private readonly IAuthService _authService; private string _userName; private string _password; private string _statusMessage; private bool _isBusy; public string UserName { get _userName; set { if (SetProperty(ref _userName, value)) LoginCommand?.RaiseCanExecuteChanged(); } } public string Password { get _password; set { if (SetProperty(ref _password, value)) LoginCommand?.RaiseCanExecuteChanged(); } } public string StatusMessage { get _statusMessage; set SetProperty(ref _statusMessage, value); } public bool IsBusy { get _isBusy; set SetProperty(ref _isBusy, value); } public RelayCommand LoginCommand { get; } public LoginViewModel(IAuthService authService) { _authService authService; LoginCommand new RelayCommand(ExecuteLogin, CanExecuteLogin); } private bool CanExecuteLogin() { return !string.IsNullOrWhiteSpace(UserName) !string.IsNullOrEmpty(Password) !IsBusy; } private async void ExecuteLogin() { IsBusy true; StatusMessage 正在登錄...; try { var user await _authService.LoginAsync(UserName, Password); StatusMessage $歡迎你{user.DisplayName}; } catch (Exception ex) { StatusMessage $登錄失敗{ex.Message}; } finally { IsBusy false; LoginCommand.RaiseCanExecuteChanged(); } } }這個ViewModel有幾個地方是經(jīng)驗沉淀出來的。第一UserName和Password的setter里在值變化后調(diào)用了LoginCommand.RaiseCanExecuteChanged()保證輸入內(nèi)容變化時按鈕的可用狀態(tài)立刻刷新。第二用IsBusy在登錄期間鎖住按鈕防止用戶反復提交。第三ExecuteLogin里把異常捕獲并轉(zhuǎn)成用戶可讀的狀態(tài)消息而不是讓異常直接冒泡到UI線程導致崩潰。對應的View綁定就非常直白TextBox Text{Binding UserName, UpdateSourceTriggerPropertyChanged} / PasswordBox PasswordChangedPasswordBox_PasswordChanged / Button Content登錄 Command{Binding LoginCommand} / TextBlock Text{Binding StatusMessage} /注意密碼框有一點繞WPF的PasswordBox出于安全考慮不提供綁定依賴屬性所以要手動在后臺代碼里把密碼轉(zhuǎn)發(fā)給ViewModel。這算MVVM里為數(shù)不多“需要破例”的地方我一般的做法是在PasswordChanged事件里寫一行((LoginViewModel)DataContext).Password passwordBox.Password;這種例外是框架限制導致的不必為了教條而強行不用代碼后臺。3.4 服務定位與依賴注入的引入時機在上面的例子里LoginViewModel的構(gòu)造函數(shù)接收了一個IAuthService參數(shù)。那這個參數(shù)從哪來這就是依賴注入DI要解決的問題。最簡單的做法是不用任何框架在創(chuàng)建ViewModel的地方手動newvar vm new LoginViewModel(new HttpAuthService());小項目這么做沒問題但服務一多手動管理依賴就會亂。WPF社區(qū)里常用的做法是引入一個輕量級DI容器比如Microsoft.Extensions.DependencyInjectionApp啟動時注冊所有服務ViewModel通過構(gòu)造函數(shù)自動解析。這樣做的價值在項目中期才體現(xiàn)出來——你想給某個服務加緩存實現(xiàn)時只改注冊代碼所有使用方完全不用動。依賴注入的引入時機我建議看項目體量如果只有兩三個ViewModel手動裝配完全夠用一旦超過五六個或者服務之間有互相依賴就越早引入越好。別在項目初期糾結(jié)用什么高級框架先把分層做好后面替換成本很低。4. 主流平臺MVVM實踐對照4.1 WPF/WinForm微軟生態(tài)的MVVM玩法WPF是MVVM的原生主場。它從誕生起就內(nèi)置了完整的數(shù)據(jù)綁定、命令、模板、樣式系統(tǒng)本質(zhì)上就是為MVVM準備的。在WPF里做MVVM你只需要關注ViewModel怎么寫View的綁定在XAML里完成框架替你處理了絕大部分苦力工作。WinForm的情況比較特殊它是控件驅(qū)動的舊框架沒有原生數(shù)據(jù)綁定管道。社區(qū)里常見的做法是引入第三方MVVM框架比如之前我接觸過的一些團隊在WinForm上用MVVMLight的移植版或者CommunityToolkit.Mvvm通過給控件手動掛事件、在事件處理器里轉(zhuǎn)發(fā)給命令來實現(xiàn)。效果打個折扣但至少邏輯能分離。這里分享一個我對WinForm項目的判斷如果項目是從零開始的新的桌面項目優(yōu)先考慮WPF或者后來興起的跨平臺UI方案。如果必須基于老WinForm代碼繼續(xù)迭代硬套MVVM不如做“分步改造”——先把業(yè)務邏輯從窗體代碼里抽到獨立的服務類把窗體的數(shù)據(jù)訪問改成屬性驅(qū)動再逐步引入綁定和命令。一口氣重構(gòu)在WinForm里風險太高。4.2 Android官方推薦的MVVM組合Android從2017年左右開始官方推薦MVVM架構(gòu)Jetpack組件里的ViewModel、LiveData、DataBinding以及后來的StateFlow組合起來就是一套非常完整的MVVM實踐。Android里的ViewModel和桌面端的ViewModel在設計上有一些差異。Android的ViewModel是生命周期感知組件它在配置變更比如旋轉(zhuǎn)屏幕時不會被銷毀數(shù)據(jù)因此得以存活這是為移動端場景專門設計的生命周期機制。LiveData或者StateFlow充當了數(shù)據(jù)綁定的角色——ViewModel暴露可觀察的數(shù)據(jù)界面訂閱這些數(shù)據(jù)并更新UI。class LoginViewModel(private val authRepository: AuthRepository) : ViewModel() { private val _userName MutableStateFlow() val userName: StateFlowString _userName.asStateFlow() private val _uiState MutableStateFlowLoginUiState(LoginUiState.Idle) val uiState: StateFlowLoginUiState _uiState.asStateFlow() fun onUserNameChanged(input: String) { _userName.value input } fun login() { viewModelScope.launch { _uiState.value LoginUiState.Loading val result authRepository.login(_userName.value, _password.value) _uiState.value LoginUiState.Success(result) } } }Android MVVM里我特別想提醒的是“狀態(tài)提升”State Hoisting思路UI狀態(tài)被集中封裝成不可變的UiState對象界面根據(jù)狀態(tài)決定顯示什么而不是每個屬性單獨暴露。這樣界面渲染只有一條決策鏈狀態(tài)越多優(yōu)勢越明顯。4.3 QtC世界的MVVM變體Qt的推薦做法里很多人習慣用Model/View框架但它和MVVM并不完全是一回事。Qt社區(qū)里最貼近MVVM的是QML加Qt Quick這套組合QML對應ViewC類通過繼承QObject并暴露屬性給QML訪問天然支持屬性綁定這一層就相當于ViewModel。Qt里做MVVM的核心機制是信號槽和屬性綁定。C端的類通過Q_PROPERTY宏暴露可綁定的屬性屬性變化時發(fā)出信號QML端用onXxxChanged或者在布局里直接綁定到屬性名改動一處界面自動聯(lián)動class LoginViewModel : public QObject { Q_OBJECT Q_PROPERTY(QString userName READ userName WRITE setUserName NOTIFY userNameChanged) Q_PROPERTY(QString statusMessage READ statusMessage WRITE setStatusMessage NOTIFY statusMessageChanged) public: Q_INVOKABLE void login(); signals: void userNameChanged(); void statusMessageChanged(); };Qt MVVM實操中最大的坑是數(shù)據(jù)同步線程模型。C里耗時操作跑在工作線程完成后要跨線程更新屬性稍不小心UI線程就被卡頓甚至崩潰。我建議所有耗時操作通過信號跨線程返回再用QMetaObject::invokeMethod把UI更新調(diào)度回主線程別在子線程里直接改屬性。4.4 不同平臺MVVM實現(xiàn)對比表平臺View層ViewModel載體綁定機制典型坑點WPFXAMLINotifyPropertyChanged依賴屬性綁定綁定失效時不報錯靜默WinForm窗體控件普通類事件轉(zhuǎn)發(fā)框架不原生支持綁定AndroidCompose/XMLJetpack ViewModelLiveData/StateFlow生命周期泄漏QtQMLQObject派生類屬性系統(tǒng)信號槽跨線程更新UI這張表想表達的核心信息是MVVM是思想而不是具體API它在不同平臺的實現(xiàn)差異很大但底層的“數(shù)據(jù)驅(qū)動UI、邏輯可測試”這個內(nèi)核是通用的。你在一套平臺上真正理解了MVVM換平臺時只是重新學習綁定語法而已。5. MVVM常見問題與排查技巧實錄5.1 綁定不生效八成是這幾個原因做MVVM一定會遇到“界面死活不更新”的情況。根據(jù)我的經(jīng)驗90%的綁定不生效可以歸因到以下幾類。一是屬性沒有通知。ViewModel的屬性本身變化了但沒有觸發(fā)PropertyChanged事件綁定引擎不知道數(shù)據(jù)變了。檢查方法是看屬性定義里是否用了SetProperty如果你的代碼是_userName value然后沒有調(diào)用通知那頁面不可能刷新。二是通知了錯誤的屬性名。當視圖綁定了UserName但通知寫成了Username少一個N綁定引擎找不到匹配靜默失敗。三是DataContext沒有設置。ViewModel沒有掛到界面的數(shù)據(jù)上下文上綁定找不到來源這種情況在控制臺會有綁定錯誤輸出但很多人忽略它。四是綁定的屬性路徑寫錯比如控件綁到了ViewModel的一個子對象的屬性上但子對象是null也會導致沒有反應。排查綁定問題的推薦工具是調(diào)試時看一眼輸出窗口。WPF的綁定錯誤會打印到調(diào)試輸出里格式大致是BindingExpression path error: Xxx property not found看到這個信息基本就能定位。我在編碼時習慣先關掉“僅我的代碼”讓綁定錯誤全部顯示出來不然有些錯誤被吞掉排查效率非常低。5.2 ViewModel內(nèi)存泄漏的排查與規(guī)避MVVM架構(gòu)里有一個企業(yè)級項目一定會踩的坑ViewModel和View互相引用導致對象無法被垃圾回收。典型的場景是這樣的View構(gòu)造ViewModel并為其掛上事件訂閱比如訂閱了某個全局消息或服務的通知事件但View關閉時忘了取消訂閱。由于事件發(fā)布者持有訂閱者引用你的ViewModel甚至整個View都不會被釋放內(nèi)存占用越來越高。我在排查這類泄漏時的經(jīng)驗是關掉界面的生命周期里主動調(diào)用ViewModel的Cleanup方法把事件訂閱全部解除。另一個常見泄漏源頭是命令綁定導致的事件持有。某些框架里按鈕的Command綁定會讓我方持有View如果我在View的代碼里手動訂閱了CommandManager的RequerySuggested而不取消也會形成引用鏈。我的經(jīng)驗是ViewModel里的事件盡量用弱事件模式WeakEvent或者統(tǒng)一在Cleanup里退訂雙保險。5.3 過度MVVM化架構(gòu)潔癖的成本MVVM是一個工具不是信仰。我在項目里見過最離譜的做法是連一個簡單的提示框彈窗都要走命令加服務一個只讀的Label顯示固定文本也要建一個ViewModel屬性一個窗口里十幾個控件每個都要綁定一個命令。這種過度設計讓簡單的功能寫起來復雜了三倍團隊成員每次改需求都要在五六個文件之間來回跳。有一個判斷標準可以幫你拿捏分寸如果一個操作只是純粹的UI行為比如調(diào)整窗口大小、收起展開某個面板不涉及業(yè)務邏輯和數(shù)據(jù)處理那完全可以直接寫事件處理沒必要套命令。如果一個屬性只是界面內(nèi)部狀態(tài)、不需要持久化也不需要被其他邏輯消費那也沒必要放進ViewModel。MVVM的價值在于讓業(yè)務邏輯變得可測試和可維護而不是讓所有UI代碼都禁止出現(xiàn)在View層。5.4 異步操作的競態(tài)問題處理MVVM里大量涉及異步操作比如登錄、加載列表、上傳文件。一個隱蔽的問題叫“競態(tài)條件”用戶先后觸發(fā)了兩次異步操作第一次的結(jié)果還沒回來第二次的結(jié)果先到了界面顯示的數(shù)據(jù)是新舊混雜的。標準做法是引入“請求序號”機制。每次發(fā)起異步操作時遞增一個計數(shù)器異步結(jié)果回來時檢查序號是否還是自己發(fā)起操作時的序號如果不是就丟棄結(jié)果。這種方法在WPF和Android里都適用代碼也不復雜private int _requestId; private async void ExecuteLoad() { var currentId _requestId; IsBusy true; try { var result await _service.LoadAsync(); if (currentId ! _requestId) return; // 過期結(jié)果直接丟棄 Items result; } finally { IsBusy false; } }這個問題在舊的項目里幾乎沒人處理因為傳統(tǒng)事件驅(qū)動開發(fā)中異步回調(diào)也是同樣的問題但MVVM的封裝讓異步操作變得更多更密集所以更值得重視。特別是做移動端或者數(shù)據(jù)刷新頻繁的桌面應用競態(tài)處理一定要做到位。6. 踩坑三四年后我對MVVM的個人體會6.1 什么時候不該用MVVM聊了這么多MVVM的好處我也想潑點冷水。不是所有項目都適合上MVVM。如果你的項目只是一個幾千行代碼的小工具界面總共兩三個窗口業(yè)務邏輯簡單到一眼看穿強行引入MVVM只會增加代碼量和理解成本反而拖慢開發(fā)速度。我的判斷標準很簡單如果這個項目的UI邏輯需要寫單元測試或者未來大概率會不斷擴充業(yè)務比如從單窗口長成多模塊或者團隊不止一個人同時改界面和邏輯那MVVM能給你帶來明顯收益。如果只是個人寫個內(nèi)部工具、生命周期只有幾個月那保持輕量就好。架構(gòu)是為業(yè)務服務的不是為了好看。6.2 團隊協(xié)作中MVVM的約定大于配置MVVM沒有統(tǒng)一的官方標準不同人寫出來的MVVM風格差異可以非常大。有人喜歡把所有邏輯塞進ViewModel有人習慣在ViewModel里再拆業(yè)務服務層有人命令全部用AsyncRelayCommand有人只用普通RelayCommand配合async void。團隊協(xié)作時這些問題不統(tǒng)一代碼review成本會直線上升。我的建議是項目一開始就定一份簡單的MVVM約定文檔內(nèi)容包括ViewModel命名規(guī)則后綴統(tǒng)一用ViewModel、命令統(tǒng)一在構(gòu)造器里初始化、所有耗時操作必須走異步命令不允許裸用async void、服務接口一律放Services層。這些約定寫清楚之后新人上手成本會低很多代碼風格也不會五花八門。6.3 最后分享一個分組校驗的小技巧MVVM里表單校驗是個繞不開的需求。我做過一個還算好用的方案ViewModel基類里維護一個字典記錄每個屬性的錯誤信息校驗時分組執(zhí)行驗證規(guī)則把錯誤消息匯總到界面統(tǒng)一展示。public class ValidationViewModelBase : ViewModelBase { private readonly Dictionarystring, string _errors new(); public bool HasErrors _errors.Count 0; protected void ValidateProperty(string propertyName, Funcbool rule, string errorMessage) { if (rule()) { _errors.Remove(propertyName); } else { _errors[propertyName] errorMessage; } } public bool ValidateAll() !_errors.Any(); }界面只需要在按鈕命令執(zhí)行前先調(diào)ValidateAll()不符合就提示錯誤并終止操作。這套方案比挨個控件校驗要集中、可控而且能被單元測試覆蓋。團隊里后來的人加新校驗時只需要在ViewModel里多寫一行規(guī)則代碼不用去動界面這也是MVVM帶來的日常便利。MVVM這條路我走了好幾年從最開始覺得它純粹是增加工作量到后來在大型項目里嘗到甜頭再到現(xiàn)在能比較清晰地判斷什么場景該用什么程度的架構(gòu)最大的體會是架構(gòu)模式的真正價值不是讓代碼“看起來高級”而是讓未來的自己和同事改代碼時少一點提心吊膽。如果你正在一個邏輯糾纏不清的界面項目里掙扎不妨從拆一個最簡單的窗口開始用數(shù)據(jù)綁定的方式把邏輯挪進ViewModel里試試。那一步邁出去后面的路會順很多。