Swift MVVM模式·分层架构：为何不采用通知式变更请求流转？

Great question—this gets straight to the core of how MVVM optimizes responsibility and simplicity between its layers. Let’s break down why the standard direct interaction flow is preferred over a notification-based chain:

• It aligns perfectly with MVVM’s role separation
  The ViewModel is explicitly built to be the middleman between the View and Model. Its whole job is to take user interactions from the View and translate them into actions that update the Model. Directly calling Model methods or updating Model properties from the ViewModel is far more straightforward than passing "change request" notifications—you eliminate ambiguous messaging and make the intent crystal clear. The ViewModel knows exactly what needs to happen, so there’s no need to wrap that intent in an extra notification layer.

• It cuts down on unnecessary complexity
  A notification chain would require defining extra events, subscribers, and handling logic: the View fires a notification, the ViewModel listens and then fires another notification to the Model, and so on. This adds redundant code, increases the chance of bugs (like missed subscriptions or event ordering issues), and introduces unnecessary performance overhead from event dispatching. Direct interaction keeps the flow tight and easy to follow.

• It plays nice with MVVM’s data binding foundation
  MVVM relies heavily on data binding to sync the View and ViewModel. When a user interacts with the View (e.g., clicking a button, editing a text field), this triggers a bound command or property change in the ViewModel. That command/property setter can immediately handle updating the Model—no extra notification needed. The reverse flow (Model → View) uses notifications (like INotifyPropertyChanged) because the Model can update independently, but the forward flow (View → Model) is driven by user intent that the ViewModel can act on directly.

• It boosts testability
  One of MVVM’s biggest wins is testable ViewModels. If your ViewModel directly interacts with the Model, you can inject a mock Model into the ViewModel and call its methods directly to verify that the Model gets updated correctly. With a notification chain, you’d have to simulate the View sending a notification, then verify the ViewModel sends the right notification to the Model—adding extra steps and making tests more brittle.

That said, notification-based flows can have their place in complex cross-component scenarios, but for standard View-to-Model updates in MVVM, direct interaction is the cleaner, more idiomatic approach.

内容的提问来源于stack exchange，提问作者Vince O'Sullivan