MVP Architecture en Unity

Diagrama

Introduccion

MVP (Model View Presenter) es un patrón de arquitectura, esto quiere decir que nos brinda una estructura para organizar nuestro software y aumentar la escalabilidad y el mantenimiento del proyecto. En esta guia voy a estar repasando una de tantas implementacion de MVP y la que creo es la mas util.

De que nos sirve implementar esta arquitectura

Implementar esta arquitectura nos ayuda a poder centrarnos mas en el problema a resolver y no en como organizarlo, ademas sirve para poder separar toda la lógica de negocio/ Dominio de la forma en la que se muestra y así poder hacer sistemas mas abstractos, testeables y extensibles. Ademas tiene un proposito mucho mayor que es crear una comunicacion eficiente entre los miembros del equipo, ya que al estar todos implementado la misma arquitectura todos hablan el mismo idioma y no hay problemas entender los codigos de los demas.

¿Qué es lógica de Negocio o Dominio?

Es donde se encuentra el core de nuestro programa, en el esta toda la logica que resuelve el problema, tambien es tomada como aquella funcionalidad ofrecida por el software.

Por ejemplo: en un sistema de login nuestro dominio es todo lo que tenga que ver con tratar de hacer login, es decir:

• Comprobar la contraseña.
• Que el usuario exista.
• Que tanto el usuario como la contraseña sean correcto.
• Hacer llamadas al servidor.

Por lo tanto todos los demas elementos del sistema estan fuera del dominio por ejemplo:

• El input field donde se pone el usuario.
• El botón de hacer login.
• La animación que se hace cuando carga la UI.

Dependency Rule

En esta implementacion de MVP se aplica La Regla de la Dependencia (Dependency Rule o DR)

La DR es un principio que dice que la comunicacion entre capas tendra solo una direccion, como se ve en el diagrama superior las flechas solo tienen una direccion, la view solo conoce al presenter y el presenter solo al model, al aplicar esto se implementa implicitamente la inversion de dependencias.

Boundaries

Si quisieramos comunicar el Presenter con la View, a primeras no podriamos ya que la capa de Presenter no conoce a la capa de View, entonces es cuando aplicamos Inversion de Dependecias (DI), para solucionar esto se crea una Interface IView que pertenece a la capa del presenter, por lo que el este puede usarla para todo lo que necesite, luego View ya que conoce a la capa de presenter podra implementar a IView y a traves de Dependecy injection podremos inyectar a View en IView.

Esto se lo conoce lo boundary, y es la interaccion que tienen las capas a traves de interfaces.

Mas adelante veremos como aplicar esto correctamente.

Capas

MVP se separa en tres capas principales y 1 una opcional:

• View.
• Presenter.
• Model.
• Installer.

View

La capa de view es la encargada de mostrar los datos y recibir inputs. Esta no contiene logica y es generalmente la unica que hereda de monobehaviour. La view va a tener las referecias a objetos que tengan que ver con el usuario, por ejemplo un button, un text, un Slider, etc; Generalmente estos objetos se los relaciona con la UI pero tambien podria ser otros elementos como gameobjects.

Esta capa solo conoce a la capa de Presenter.

Presenter

Es la encargada de recibir los datos de la view para dárselos al model y recibe datos del model(a traves de DI) para formatearlos y darselos a la view para que los muestre. Un ejemplo de esto seria un method en el Presenter llamado SetScore(int score), este es llamado por el Model y le pasa el score actual, la tarea del presenter es formatear el score, es decir transformalo al tipo de dato que necesite la view, es este caso podria ser a string, entonces lo convierte a string y se lo pasa a la view para que lo muestre en un text, el presenter tambien podria fijarse que score no sea menor a 0. Esto siempre es tarea de Presenter y a la View le tienen que llegar los datos formateados.

Esta capa si puede contener lógica ya sea para formatear los datos o lógica necesaria para la view, por ejemplo instanciar un objeto, esto queda a criterio de cada, por mi experiencia creo que es lo mejor.

Esta capa solo conoce a la capa de Model.

Model

La capa de Model es la encargada de contener toda nuestra logica de negocio / Dominio.

Dentro del model yo identifico varias sub-capas que ayudan a identificar mejor cada aspecto del dominio:

Entities: las entities son la representacion las cercana a un object, estas definen las variables y metodos que trabajan con estas variables, esta solo contiene datos que seran usados en todo el dominio. Esta capa solo se comunica con otras entities.

UseCase: Los UseCase son los encargados de contener la mayor parte de la logica de negocio y por donde se centra el flow de nuestro programa.

Gateways: La capa de Gateways en la encargada de contener todas las implementaciones que tengan que ver con conecciones a servidores o base de datos. En esta capa se encuntran los Mocks estas son implementaciones “Falsas” o “Substitutas” que se encargan de conectar a un server o Base de datos de mentira, dicho en otras palabras no se conectan a nada sino que sacan los datos del propio disco o de donde nosotros queramos, y estos sirven para poder hacer Tests o pruebas sin necesidad de implementar un server o base de datos real.

Installer

La capa de installer se encarga de construir e inicializar nuestro programa. Es una capa opcional ya que existen distintos mecanimos o principios para inicializar nuestro programa y depende de cada proyecto, en lo personal prefiero tomar los installers como una capa mas y asi lograr un nivel mas de organizacion.

Esta capa conoce a todas las demas capas y rompe con la DY pero es por un bien mayor. Si no tomamos esta practica como una capa mas, puede ocasionar que en un equipo de trabajo que no tiene bien definida la inicializacion de las clases, que cada programador las inicilice de forma distinta.

Ejemplo de un Login aplicando MVP

Si quieres ver como se aplica MVP en un login revisa mi post: https://medium.com/@laurencioberro/login-con-mvp-en-unity-e37324b6d254

Gracias por leer y espero que te sea de ayuda! cualquier duda o consulta no dudes en comentar o escribirme al mail: LaurencioBerro@gmail.com

Saludos!