Presentation Patterns

Pregunta de entrada

¿Cómo repartir representación, interacción y estado de una UI sin confundirlos con toda la arquitectura del sistema? Este MOC navega las primeras entradas de Frontend and Client Architecture / Presentation Patterns. Los canónicos contienen historia, responsabilidades, variantes y consecuencias; aquí se conservan preguntas y comparaciones.

El mapa no prescribe un framework ni una elección universal. Un nombre conocido ayuda cuando permite explicar ownership del estado y colaboración; no basta para evaluar una implementación. Si la discusión empieza por carpetas, recuperar primero la interacción que deben sostener.

Recorridos por intención

Pregunta	Documento	Qué observar
¿Quiero entender la separación original Model/View/Controller y sus adaptaciones Web?	model-view-controller	Contexto histórico, interpretación de entrada y sincronización.
¿Quiero un coordinador que manipule una View explícitamente?	model-view-presenter	Contrato de View y reparto entre Passive View y Supervising Controller.
¿Quiero exponer estado y acciones consumibles mediante binding?	model-view-viewmodel	ViewModel, notificaciones, comandos y ownership de presentación.

Para comenzar, leer MVC antes de comparar nombres. Para una UI existente, puede ser más útil entrar por su mecanismo de actualización y después contrastar las otras variantes. Ningún recorrido exige implementar los tres.

Comparación central

Las celdas describen orientaciones frecuentes, no leyes universales. Cada canonical conserva excepciones y contexto.

Dimensión	MVC	MVP	MVVM
Coordinador habitual	Controller interpreta interacción.	Presenter coordina presentación.	ViewModel expone estado y comportamiento.
Actualización de View	Varía: observación, consulta o rendering por petición.	Frecuentemente explícita; algunas variantes usan binding.	Frecuentemente mediante binding y notificaciones.
Contrato de View	Depende de la variante.	Comúnmente una abstracción explícita.	Habitualmente estado/acciones y contrato de binding.
Relación con Model	Depende de la formulación; View puede consultarlo.	Usualmente coordinada por Presenter; Supervising Controller admite relación directa.	Usualmente mediante ViewModel; puede exponer datos del Model.
Estado de UI	Distribución dependiente de la variante.	Repartido entre Presenter, View y posibles modelos editables.	Concentración frecuente en ViewModel, con estado visual en View.
Dependencia del framework	Varía entre GUI y servidor Web.	El contrato puede aislar coordinación; binding introduce otros compromisos.	El soporte de binding suele ser valioso; no prueba el patrón.
Testabilidad	Coordinación y Model pueden probarse separados; integración sigue necesaria.	Presenter aislable; View y sincronización requieren pruebas reales.	Estado/acciones aislables; bindings y controles requieren integración.

La comparación de sincronización evita una conclusión engañosa: más flechas o menos llamadas no significa más independencia. Preguntar qué decisión se puede cambiar sin modificar las otras partes y qué comportamiento demostrarán las pruebas.

Un caso para comparar: Edit Customer

Los tres canónicos usan el mismo ejemplo propio: Load customer → Edit name → Validate → Save → Display success/error. Así puede compararse reparto sin cambiar simultáneamente la necesidad.

En MVC Web, seguir la petición, delegación y representación de respuesta. En MVP, seguir eventos, operación coordinada y actualización de View, contrastando las dos variantes. En MVVM, seguir borrador, acción y estado observable que binding representa.

Durante lectura, comprobar si cada versión conserva el texto rechazado, distingue edición de estado confirmado y evita sustituir validación de negocio por feedback de pantalla. No comparar una implementación completa de un patrón con un dibujo idealizado de otro.

Composición con otras dimensiones

Modular Monolith
└── Web application
    ├── MVC presentation
    ├── Application
    ├── Domain
    └── Infrastructure
 
Desktop client
└── MVVM presentation
    └── Core organized with Ports and Adapters

Son composiciones conceptuales, no recomendaciones de distribución física. modular-monolith y architecture-profiles tratan compromisos más amplios; internal-structure organiza dependencias dentro de una unidad.

Para la primera composición, layered-architecture explica responsabilidades y reglas entre capas. Para la segunda, ports-and-adapters y hexagonal-architecture explican inside/outside y adaptación de interacciones. clean-architecture ayuda a distinguir dependencia de código hacia políticas de las llamadas runtime hacia mecanismos.

Una UI MVC/MVP/MVVM puede invocar un application boundary y conservar dominio independiente del toolkit. Que el resultado vuelva a la pantalla no exige que dominio importe esa pantalla. Tampoco elegir presentación decide dónde viven la base de datos o las unidades desplegables.

Clasificación y vocabulario

Presentation Patterns no es el mismo eje que architecture-profile. Organiza la interacción UI, no un paquete completo equivalente a Monolith o Microservices. Tampoco compite automáticamente con Clean o Layered.

design-pattern y architectural-pattern permiten examinar intención, alcance y consecuencias. Estas soluciones suelen abarcar más organización de presentación que una colaboración GoF local como Strategy o Decorator, pero no existe una escalera universal de tamaños. La convención editorial del Atlas se explica en architecture-pattern-terminology y se navega desde architecture-patterns.

Model no significa exclusivamente una entidad de database. Controller, Presenter o ViewModel tampoco tienen significado garantizado por el nombre que les da un framework. Volver al canonical correspondiente si una fuente mezcla términos o usa ViewModel para datos pasivos de una respuesta Web.

Preguntas para revisar una implementación

1. ¿Quién posee el borrador y quién acepta la modificación definitiva?
2. ¿Cómo conoce View un cambio y cuándo alcanza el coordinador la entrada editable?
3. ¿Qué lógica depende de controles y qué regla debe sobrevivir a otro canal?
4. ¿Quién traduce rechazo, conflicto y éxito a una representación comprensible?
5. ¿Qué pruebas ejercitan decisiones aisladas y cuáles verifican sincronización real?
6. ¿Las carpetas reflejan responsabilidades o solamente convenciones de nombres?

Estas preguntas ayudan a evaluar variaciones sin declarar incorrecto un framework por diferir del original. Las respuestas concretas también revelan costos: coordinación explícita, dependencia de binding o estado duplicado.

Historia y continuación

Para contrastar definiciones, los canónicos citan Reenskaug, Potel/Taligent, Gossman y literatura de Fowler, además de documentación de los mecanismos concretos.

La cobertura de este mapa se concentra en MVC, MVP y MVVM. frontend-and-client-architecture ofrece navegación superior hacia otras dimensiones: unidirectional-data-flow examina propagación de cambios, rendering-strategies ubicación y momento de representación Web, y client-state-management ownership, alcance y lifecycle del estado. Ningún nombre de Presentation Pattern determina por sí solo dónde persiste un borrador o qué vigencia tiene una copia remota. micro-frontends trata composición y autonomía de entrega; backend-for-frontend, adaptación servidor para una experiencia. Pueden combinarse con los patrones de este mapa sin sustituir su reparto de responsabilidades. design-patterns continúa hacia las familias GoF y pattern-selection, conservando la diferencia entre interacción de presentación y colaboraciones locales.