MVVM

View ↔ ViewModel ↔ Model: the ViewModel exposes bindable state and commands.

Context

Apps with declarative binding. It is the de facto standard in mobile (Android with Jetpack ViewModel, iOS with SwiftUI, .NET MAUI) and desktop (WPF, Avalonia). On the web it shows up in reactive frameworks (Angular, Vue, Blazor).

Solution

The View binds to the ViewModel, which exposes observable properties and ICommands. The Model represents the domain.

public class OrderViewModel : INotifyPropertyChanged
{
    private string _customer = "";
    public string Customer { get => _customer; set { _customer = value; OnChange(); } }

    public ICommand SaveCommand { get; }
    public OrderViewModel(IOrderService svc) =>
        SaveCommand = new RelayCommand(async () => await svc.SaveAsync(new Order(Customer)));

    public event PropertyChangedEventHandler? PropertyChanged;
    private void OnChange([CallerMemberName] string? n = null) =>
        PropertyChanged?.Invoke(this, new(n));
}
Tradeoffs
Pro Con
Clear separation of concerns Notification boilerplate
Testable without bringing up UI Bindings difficult to debug

#Where it is used (and where it is not)

Platform Typical use
Mobile (Android, iOS/SwiftUI, MAUI) Recommended by the platforms: the ViewModel survives rotations and screen recreation, and the UI just observes state.
Desktop (WPF, Avalonia) Its birthplace: two-way binding and ICommand.
Web SPA (Angular, Vue, Blazor) Similar, but rarely called MVVM; it is "component + state".
API / backend Not applicable. There is no View to bind. Use Layered, Hexagonal or Vertical Slice there.

MVVM organizes the presentation layer of a client. It does not replace Hexagonal or Clean: they combine. In a serious mobile app, MVVM lives at the presentation edge, with use cases and repositories behind it.

#MVVM vs MVC

  • MVC: the controller receives input and picks the view. Fits request/response (server-side web).
  • MVVM: the view observes state and there is no request. Fits long-lived stateful UIs (app screens).

#Questions to decide

  1. Does the UI hold long-lived state (forms, lists, long sessions)? → MVVM.
  2. Is it request/response rendered on the server? → MVC.
  3. Does the framework already ship first-class binding and ViewModel? → use it, don't fight the platform.
  4. Is it a 2-field screen? → code-behind is enough; full MVVM is boilerplate with no return.

#architecture #ui #wpf #maui