Patrón MVC o MVP: ¿cuál es la diferencia?

A lo largo de los años, he asesorado a muchos desarrolladores en el uso de patrones de diseño y mejores prácticas. Una pregunta que surge una y otra vez es: ¿Cuáles son las diferencias entre los patrones de Controlador de vista de modelo (MVC) y Presentador de vista de modelo (MVP)?

Sorprendentemente, la respuesta es más compleja de lo que se podría sospechar. Parte de las razones por las que creo que muchos desarrolladores evitan usar cualquiera de los dos patrones es la confusión sobre las diferencias.

Antes de profundizar en las diferencias, examinemos cómo funcionan los patrones y los beneficios clave de usar cualquiera de ellos. Ambos patrones (MVC y MVP) se han utilizado durante varios años y abordan un principio clave de OO, a saber, la separación de preocupaciones entre la interfaz de usuario y las capas de negocio. Hay una serie de marcos que se utilizan hoy en día que se basan en estos patrones, incluidos JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB),​ ​Microsoft Web Client Software Factory y el marco MVC ASP.Net recientemente anunciado.

Model View Controller (MVC) Pattern

El patrón MVC es un patrón de presentación de la interfaz de usuario que se centra en separar la interfaz de usuario (vista) de su capa de negocio (modelo). El patrón separa las responsabilidades entre tres componentes: la vista es responsable de rasgar los elementos de la interfaz de usuario, el controlador es responsable de responder a las acciones de la interfaz de usuario y el modelo es responsable de los comportamientos empresariales y la administración de estados. En la mayoría de las implementaciones, los tres componentes pueden interactuar directamente entre sí y, en algunas implementaciones, el controlador es responsable de determinar qué vista mostrar (patrón de controlador frontal),

Model View Presenter (MVP) Pattern

El patrón MVP es un patrón de presentación de la interfaz de usuario basado en los conceptos del patrón MVC. El patrón separa las responsabilidades en cuatro componentes: la vista es responsable de rasgar los elementos de la interfaz de usuario, la interfaz de vista se usa para acoplar de forma flexible el presentador de su vista, el presentador es responsable de interactuar entre la vista o el modelo y el modelo es responsable de los comportamientos empresariales y la administración de estado. En algunas implementaciones, el presentador interactúa con una capa de servicio (controlador) para recuperar o conservar el modelo. La interfaz de vista y la capa de servicio se usan normalmente para facilitar la escritura de pruebas unitarias para el presentador y el modelo.

Key Benefits

Antes de usar cualquier patrón, un desarrollador debe considerar los pros y los contras de usarlo. Hay una serie de beneficios clave al usar el patrón MVC o MVP (consulte la lista a continuación). Pero también hay que tener en cuenta algunos inconvenientes. Los mayores inconvenientes son la complejidad añadida y la curva de aprendizaje. Si bien los patrones pueden no ser apropiados para soluciones simples; Las soluciones avanzadas pueden beneficiarse enormemente del uso del patrón. Según mi experiencia, he visto algunas soluciones que eliminan una gran cantidad de complejidad, pero que se refactorizan para usar cualquiera de los patrones.

• Acoplamiento flexible: el presentador y el controlador son intermediarios entre el código de la interfaz de usuario y el modelo. Esto permite que la vista y el modelo evolucionen independientemente el uno del otro.
• Clara separación de preocupaciones y responsabilidades

o UI (Formulario o Página) – Responsable de rasgar los elementos de la UI

o Presentador/controlador: responsable de reaccionar a los eventos de la interfaz de usuario e interactúa con el modelo

o Modelo: responsable de los comportamientos empresariales y de la gestión del estado.

• Controlado por pruebas: al aislar cada componente principal (interfaz de usuario, presentador/controlador y modelo), es más fácil escribir pruebas unitarias. Esto es especialmente cierto cuando se usa el patrón MVP, que solo interactúa con la vista mediante una interfaz.
• Reutilización de código: mediante el uso de un enfoque de separación de preocupaciones / diseño responsable, aumentará la reutilización de código. Esto es especialmente cierto cuando se utiliza un modelo de dominio completo y se mantiene toda la lógica de administración de negocios/estado donde pertenece.
• Ocultar el acceso a los datos: el uso de estos patrones le obliga a colocar el código de acceso a los datos donde pertenece en una capa de acceso a los datos. Hay una serie de otros patrones que normalmente funcionan con el patrón MVP/MVC para el acceso a los datos. Dos de los más comunes son el repositorio y la unidad de trabajo. (Ver Martin Fowler – Patrones de Arquitectura de Aplicaciones Empresariales para más detalles)
• Flexibilidad/adaptable: al aislar la mayor parte del código en los componentes del presentador/controlador y del modelo, la base de código es más adaptable a los cambios. Por ejemplo, considere cuánto han cambiado las tecnologías de interfaz de usuario y acceso a datos a lo largo de los años y la cantidad de opciones que tenemos disponibles en la actualidad. Una solución de diseño adecuado que utilice MVC o MVP puede admitir tecnologías de acceso a datos y múltiples interfaces de usuario al mismo tiempo.

Diferencias clave

Entonces, ¿cuáles son realmente las diferencias entre el patrón MVC y MVP? En realidad, no hay muchas diferencias entre ellos. Ambos patrones se centran en separar la responsabilidad entre varios componentes y promueven el acoplamiento flexible de la interfaz de usuario (vista) de la capa de negocio (modelo).  Las principales diferencias son cómo se implementa el patrón y, en algunos escenarios avanzados, se necesitan presentadores y controladores.

Estas son las diferencias clave entre los patrones:

MVP Pattern

• La vista está más vagamente acoplada al modelo. El presentador es responsable de vincular el modelo a la vista.
• Es más fácil realizar pruebas unitarias porque la interacción con la vista se realiza a través de una interfaz
• Por lo general, el mapa de visualización del presentador uno a uno. Las vistas complejas pueden tener varios presentadores.

MVC Pattern

• Los controladores se basan en comportamientos y se pueden compartir entre vistas
• Puede ser responsable de determinar qué vista mostrar (patrón de controlador frontal)

Con suerte, esta publicación le resultó interesante y ayudó a aclarar las diferencias entre el patrón MVC y MVP. Si no es así, no te desanimes, los patrones son herramientas poderosas que a veces pueden ser difíciles de usar. Una cosa que hay que recordar es que un patrón es un plano y no una solución lista para usar. Los desarrolladores deben usarlos como guía y modificar la implementación de acuerdo con su dominio de problema.