MVP o MVVM? Recientemente publiqué un artículo que muestra… | de Prinzly Ngassa | Octubre de 2020

¿Qué pasa si alguien me pregunta qué patrón debo usar entre MVP y MVVM para el desarrollo de aplicaciones de Android? Este artículo responde a esta pregunta enfatizando las diferencias entre los dos patrones.

MVVM significa Model View ViewModel.

Y MVP es una abreviatura de Model View Presenter.

La principal diferencia es Presenter versus ViewModel. Para mostrar los pros y los contras, iré con un caso de uso específico: cargar el perfil de usuario y mostrarlo en la vista (Fragmento / actividad).

Estamos con el modelo MVP wno definiremos un acuerdo entre la Vista, donde mostraremos los datos y el Conferencista relacionados con la Vista dada.

No necesito definir un contrato entre View y ViewModel con el patrón MVVM. En ViewModel, defino los datos requeridos para ser consumidos por la Vista como LiveData y estarán vinculados a la Vista usando el enfoque DataBinding.

Utilizo DataBinding en el patrón MVVM, lo que me impide implementar todos los métodos definidos en la interfaz de pantalla utilizando el patrón MVP. MVVM es ventajoso aquí porque reducirá el número de líneas de código en la vista y hará que el diseño de la vista sea más declarativo.

Así es como se ve el Fragmento con el patrón MVVM:

Y con MVP, MainFragment se vería así:

Así es como se ve el presentador:

Y así es como se ve ViewModel:

Pruebas: Escribamos pruebas unitarias para Presenter y ViewModel.

Con el patrón MVP, puedo simular View y validar los métodos de Presenter para llamar a View.

La prueba de ViewModel confirma que estamos actualizando LiveData, pero no puedo garantizar que se hayan agregado a View porque View rastrea LiveDatas. Si olvidamos monitorear LiveData, no podemos probar que la Vista está recibiendo datos. De hecho, puedo burlarme del observador y probar que el observador está aceptando cambios en los eventos, pero esto supone que el observador será la Vista en el código de producción.

Conclusión:

  • Con MVVM, podemos aprovechar el componente de arquitectura de Android ViewModel una clase que sobrevive a la configuración cambia un Datos en tiempo realque arroja inmediatamente algunos de los valores enumerados en la documentación.
  • Cuando se trata de pruebas, tanto ViewModel como Presenter son fáciles de probar. Pero Presenter tiene mejores pruebas porque podemos verificar que se invocan los métodos View en comparación con ViewModel, donde podemos simular observadores LiveData y eventos de prueba, siempre que esos observadores puedan ser View.
  • MVVM tiene la desventaja de que si View se olvida de suscribirse a LiveDatas, no se actualizará.
  • MVVM tiene la ventaja de reducir el código de vista mediante DataBinding. Con el patrón MVP, necesitaremos implementar los métodos de contrato de la interfaz View.
  • MVP tiene la ventaja de que View no toma decisiones o implementaciones en comparación con MVVM, donde parte de la lógica aún vive en el registro.

Para mí, ambos patrones son buenos. Como desarrolladores, necesitamos saber qué es mejor para nosotros en términos de compromisos.

La documentación de Android sigue actualmente los patrones de MVVM y proporciona muchas bibliotecas para que el desarrollo sea más sencillo para los desarrolladores experimentados. Pero para alguien nuevo en el mundo del desarrollo de Android, es fácil comenzar con un patrón MVP en comparación con MVVM porque agrega complejidad.

Definitivamente necesitas agregar más. Siéntete libre de dejar tus pensamientos en los comentarios.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *