iOSArquitectura MVP


Introducción

MVP es un patrón arquitectónico, una derivación del Modelo – Vista – Controlador. Está representado por tres componentes distintos: Modelo, Vista y el Presentador. Fue diseñado para facilitar las pruebas de unidades automatizadas y mejorar la separación de inquietudes en la lógica de presentación.

En los ejemplos, encontrará un proyecto simple construido con el patrón MVP en mente.

Observaciones

Componentes:

introduzca la descripción de la imagen aquí

  • El modelo es una interfaz responsable de los datos del dominio (que se mostrarán o se ejecutarán en la GUI)
  • View es responsable de la capa de presentación (GUI)
  • Presenter es el "hombre medio" entre Model y View. Reacciona a las acciones del usuario realizadas en la Vista, recupera datos del Modelo y los formatea para mostrarlos en la Vista.

Deberes componentes:

Modelo Ver Presentador
Se comunica con la capa DB Renders datos Realiza consultas al modelo.
Levantando eventos apropiados Recibe eventos Formatos de datos del modelo
Lógica de validación muy básica. Envía datos formateados a la Vista
Lógica de validación compleja

Diferencias entre MVC y MVP :

  • La vista en MVC está estrechamente unida al controlador, la parte de vista del MVP consta de UIViews y UIViewController
  • MVP View es lo más tonto posible y casi no contiene lógica (como en MVVM), MVC View tiene cierta lógica de negocios y puede consultar el Modelo
  • MVP View maneja los gestos de los usuarios y delega la interacción con el Presentador, en MVC el Controlador maneja los gestos y comandos.
  • El patrón MVP es altamente compatible con Unit Testing, MVC tiene soporte limitado
  • MVC Controller tiene muchas dependencias de UIKit, MVP Presenter no tiene ninguna

Pros:

  • MVP hace que UIViewController sea parte del componente View, es tonto, pasivo y ... menos masivo;]
  • La mayor parte de la lógica empresarial está encapsulada debido a las vistas tontas, lo que proporciona una excelente capacidad de prueba. Se pueden introducir objetos simulados para probar la parte del dominio.
  • Las entidades separadas son más fáciles de mantener en mente, las responsabilidades están claramente divididas.

Contras

  • Escribirás más código.
  • Barrera para desarrolladores sin experiencia o para aquellos que aún no trabajan con el patrón.

Arquitectura MVP Ejemplos relacionados