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