MVVM

View ↔ ViewModel ↔ Model: el ViewModel expone estado bindable y comandos.

Contexto

Apps con binding declarativo. Es el estándar de facto en mobile (Android con Jetpack ViewModel, iOS con SwiftUI, .NET MAUI) y en desktop (WPF, Avalonia). En web aparece en frameworks reactivos (Angular, Vue, Blazor).

Solución

La View se enlaza por binding al ViewModel, que expone propiedades observables y ICommands. El Model es el dominio.

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 Contra
Separación clara de responsabilidades Boilerplate de notify
Testeable sin levantar UI Bindings difíciles de depurar

#Dónde se usa (y dónde no)

Plataforma Uso típico
Mobile (Android, iOS/SwiftUI, MAUI) Es lo recomendado por las plataformas: el ViewModel sobrevive a rotaciones y recreaciones de la pantalla, y la UI solo observa estado.
Desktop (WPF, Avalonia) Su lugar de origen: binding bidireccional y ICommand.
Web SPA (Angular, Vue, Blazor) Se parece, pero rara vez se lo llama MVVM; es "componente + estado".
API / backend No aplica. No hay View que bindear. Ahí usá Layered, Hexagonal o Vertical Slice.

MVVM organiza la capa de presentación de un cliente. No reemplaza a Hexagonal o Clean: se combinan. En una app mobile seria, MVVM vive en el borde de presentación y detrás hay casos de uso y repositorios.

#MVVM vs MVC

  • MVC: el controller recibe el input y elige la vista. Encaja en request/response (web server-side).
  • MVVM: la vista observa estado y no hay request. Encaja en UIs con estado de larga vida (pantallas de una app).

#Preguntas para decidir

  1. ¿La UI tiene estado que vive mucho (formularios, listas, sesiones largas)? → MVVM.
  2. ¿Es request/response renderizado en el servidor? → MVC.
  3. ¿El framework ya trae binding y ViewModel de primera clase? → usalo, no pelees contra la plataforma.
  4. ¿Es una pantalla de 2 campos? → code-behind alcanza; MVVM completo sería boilerplate sin retorno.

#architecture #ui #wpf #maui