Articles

Patrón arquitectónico MVP

En este artículo, descubriremos algo sobre el patrón MVP, que se hereda del patrón MVC. Pero definitivamente, tiene algunos cambios en comparación con el patrón MVC. Por lo tanto, vamos a entender cómo usarlo, cómo diferenciar entre el patrón MVC y el patrón MVP.

Comencemos.

  • Análisis del Problema
  • Definición de Patrón MVP
  • Cuando usar
  • Beneficios & Inconveniente
  • ajuste de

el Problema del Análisis

La precaución de que nació patrón MVP es el mismo que con el patrón MVC. Pero MVP se usa para evitar algunos inconvenientes del patrón MVC, como:

  • En el patrón MVC, la vista y el modelo pueden interactuar entre sí. Por lo tanto, generalmente validamos los datos del modelo o usamos la lógica de datos en View. Por lo tanto, dificulta las pruebas unitarias automatizadas.
  • es relevante para la seguridad.

Definición del patrón MVVM

Según wikipedia.com, tenemos la definición de patrón MVP:

MVP pattern is a derivation of the Model-View-Controller (MVC) architectural pattern, and is used mostly for building user interfaces.In MVP, the presenter assumes the functionality of the middle-man.In MVP, all presetation logic is pushed to the presenter.

Y el patrón MVP se originó a principios de la década de 1990 en Taligent, una empresa conjunta de Apple, IBM y Hewlett-Packard.

A continuación se muestra el contenido de cada parte del patrón MVP.

  • El Modelo tiene entidades y servicios.Las entidades

    se utilizan para contener datos que se asignan con tabla en la base de datos por otras razones.

    Los servicios, que se pueden usar como patrón de DAO, o Patrón de repositorio, son capas finas entre la capa de Aplicación y la Capa de Acceso a Datos. Normalmente gestionan operaciones CRUD con base de datos en local o remoto.

  • La vista tiene responsabilidades que interactúan con los usuarios.

    No contiene ninguna lógica. Dirigirá las entradas y comandos (eventos) del usuario al Presentador.

    La vista generalmente tiene una referencia a su Presentador.

  • El Presentador es la parte intermedia entre la Vista y el Modelo. Jugará el mismo papel que el Controlador en el patrón MVC.

    Toda la lógica de negocio, la lógica de datos, la validación de entradas, la recepción de eventos de las Vistas, la conversión de datos de la Vista al Modelo o del Modelo a la Vista se implementa en Presenter.

    En comparación con la Vista y el Controlador en el patrón MVC, la Vista y el Presentador presentes en el patrón MVP están completamente desacoplados entre sí y se comunican mediante una interfaz. (El Presentador interactúa con las Vistas a través de la interfaz de vista, lo que significa que el Presentador puede realizar todas las tareas de presentación y navegación sin depender de la tecnología de interfaz de usuario real que se esté utilizando)

    Y tenemos un diagrama de secuencia del patrón MVP:

Cuándo usar

  • Nuestra pantalla tiene bi-directional-flow, significa que las interacciones del usuario deben solicitar algo de nuestro Modelo, y el resultado de esta solicitud afectará la vista.

  • Las vistas afectadas por las actualizaciones del modelo son muy limitadas.

  • El patrón MVP no se utiliza en un caso en el que la interfaz de usuario se actualiza sin interacciones de usuario, como actualizar la interfaz de usuario cuando ocurre un evento en el modelo, este enfoque se acerca más a MVVM que a MVP.

Beneficios & Inconveniente

  1. Beneficios
    • La Vista no interactúan directamente con el Modelo. Esto aísla mejor la implementación de la vista que en MVC y permite realizar pruebas unitarias automatizadas más fáciles del Presentador y el Modelo.

    • La posibilidad de cambiar la interfaz de usuario de Web a Ventana o Móvil es muy fácil.

    • Bajo costo de mantenimiento

  2. Inconvenientes
    • El Presentador tiende a expandirse a una enorme clase omnisciente si no somos lo suficientemente cuidadosos y no rompemos nuestro código de acuerdo con el Principio de Responsabilidad Única.

    • Aumento de la complejidad.

    • Extra curva de aprendizaje.

Algunos patrones que son relevantes para el patrón MVP

  • Application Controller – Si los presentadores interactúan con un controlador de aplicación, los presentadores no necesitan flujo de página ni lógica de navegación de pantalla. Esto hace que sea más fácil actualizar el flujo de página.

  • Observer pattern

el ajuste de

  • El usuario final interactúa sólo con la Vista.

  • Una vista se asigna solo a un presentador.

  • Ver referencias al presentador pero no tiene referencia al Modelo. Y el Presentador también es consciente de la Vista que se asocia con ella.

  • El patrón facilita la comunicación bidireccional entre la Vista y el Presentador.

  • Hay otras dos implementaciones del patrón MVP, como la Vista pasiva y el Controlador de supervisión.

    • La vista pasiva está completamente controlada por el Presentador. Al implementar la vista pasiva de MVP, es mucho más fácil manejar la concurrencia y los subprocesos múltiples.

    • En la supervisión del Presentador, la vista interactúa directamente con el Modelo para realizar cualquier enlace de datos simple que se pueda definir declarativamente, sin el Presentador. El Presentador actualiza el Modelo. Solo cambia el estado de la vista cuando se requiere una lógica de interfaz de usuario compleja que no se puede especificar declarativamente.

    • En comparación con otras variaciones de MVP, como la vista pasiva, el patrón de supervisión del Presentador hace que el código más simple sea una prioridad más alta que la capacidad de prueba completa. El patrón de presentador supervisor requiere menos código que otros patrones MVP porque utiliza enlace de datos. El código es más fácil de mantener porque los cambios simples de interfaz de usuario no requieren cambios de código en el Presentador para actualizar la vista.

Consulte:

https://www.linkedin.com/pulse/mvp-architecture-pattern-small-article-khaled-kassem/

Book Architectural Patterns_ Uncover essential patterns in the most indispensable realm of enterprise architecture

https://www.oreilly.com/library/view/architectural-patterns/9781787287495/38abcb95-0392-4127-a3fa-b80ac2807aa9.xhtml

The other idea about Presenter in MVP pattern and Controller in MVC pattern

http://hannesdorfmann.com/mosby/mvp/

Choose MVP pattern over MVC pattern

Why Do You Need to Choose MVP Over MVC Android Architectural Pattern?

Examples for MVP pattern

http://aviadezra.blogspot.com/2008/10/model-view-presenter-design-pattern.html

https://www.raywenderlich.com/7026-getting-started-with-mvp-model-view-presenter-on-android

https://www.linkedin.com/pulse/when-use-mvc-mvp-mvvm-nothing-ahmed-adel/

A Model View Presenter (MVP) implementation with ASP.NET

A brief introduction to a cleaner Android architecture: The MVP pattern

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff649571(v=pandp.10)