WPF 數據綁定驗證機制深度剖析：從 ValidationRule 到 IDataErrorInfo 的遷移之路

WPF 數據綁定驗證 (Validation) 在 3.0/3.5 版本存在顯著易用性缺陷。本文從實戰角度分析 ValidationRule 的局限，闡述 IDataErrorInfo / DataErrorValidationRule (3.5) 及 BindingGroup (3.5 SP1) 的演進邏輯，揭示隱藏 UI 不自動驗證、手動驗證與 UI 同步衝突、IsDirty 模式衝突等核心痛點。

ValidationRule 的天花板

簡單規則 (StringRequiredRule, RegexValidationRule) 可復用，但無法訪問被驗證對象的其他屬性或上下文。例如驗證 Person.Age 需對比 MinAge/MaxAge (同屬性)，或驗證 Parent 導航屬性 (關聯對象)，在 3.0 的 ValidationRule.Validate 中完全無法獲取實例引用。

演進：IDataErrorInfo 與 DataErrorValidationRule (3.5)

• IDataErrorInfo (1.0 即存在) 讓實體類自我描述錯誤：string this[string columnName] 返回錯誤信息，string Error 整體錯誤。
• DataErrorValidationRule 橋接綁定引擎與 IDataErrorInfo，使綁定自動調用索引器驗證。
• 優勢：驗證邏輯可寫在實體類或獨立驗證器中 (單一職責)，可訪問完整實例上下文。
• 遺留系統遷移：若領域模型已實現 IDataErrorInfo，低成本接入 WPF 驗證體系。

四大實戰痛點 (3.5 環境下)

1. 隱藏 UI 不觸發驗證：Visibility=Collapsed 或未加載的控件，綁定引擎不會自動調用驗證。導致實體狀態變更 (如刪除集合項) 產生的多錯誤無法即時反映。
2. 手動驗證與 UI 同步斷層：調用 Validation.GetErrors 或手動觸發驗證後，UI 不會自動顯示 ErrorTemplate (紅框)。必須手動觸發 PropertyChanged 迫使 UI 重新綁定驗證，但這又會...
3. IsDirty 模式衝突：CSLA.NET 等框架用 PropertyChanged 維護 IsDirty 標記。為驗證而強行觸發 PropertyChanged 會污染「髒狀態」判斷，引發保存邏輯誤判。
4. 錯誤集合維護複雜：實體層面需維護 Errors 列表 (CRUD)，綁定層面又需同步，雙重維護成本高。

出路：BindingGroup (3.5 SP1) 與 .NET 4.0

• BindingGroup 允許在提交時 (如表單保存) 統一驗證整個對象圖，可訪問所有綁定項，解決跨屬性/關聯對象驗證。
• .NET 4.0 (實質 WPF 完整版) 引入 INotifyDataErrorInfo (異步驗證)、ValidationError 事件、更完善的 BindingGroup 行為，徹底解決上述痛點。

面對 3.0/3.5 的簡陋，跟進版本非選擇題，而是生存題。若被迫停留舊版，需自建驗證上下文管理器、手動同步 UI 錯誤狀態、隔離 IsDirty 邏輯，工程成本極高。