MVP - Model View Presenter

Esta arquitectura resuelve varios detalles que se presentan cuando tienes una aplicación
con MVC. No toda la responsabilidad debe caer en nuestro MainActivity porque esto
podría ocasionar errores de fluidez haciéndola crashear al haber un proceso pesado en el
hilo principal de la aplicación.
MVP organiza mejor la distribución de archivos y define las responsabilidades de otra
forma.
 Model: Igual que en MVC, no hay cambios acá.
 View: Ahora el Activity/Fragment es considerado parte de la vista y dejamos de
tenerlo en el Controller como ocurre en la arquitectura anterior.
 Presenter: Es como el Controller de MVC, pero va a estar orquestando todo lo
que sucede. Es como un mesero qué se comunicará con el cocinero (modelo)
para traer lo que pide la vista. Debería haber un Presenter por cada Activity o
Fragment.
Esto hace todo mucho más limpio y facilita la realización de unit tests a la lógica
del presenter porque no esta unida a una vista específica o APIs de Android.
Ventajas

 Hace que la vista sea tonta para que pueda intercambiar la vista fácilmente.
 Reutilizable de vista y presentador
 El código es más legible y mantenible
 Pruebas sencillas ya que la lógica de negocios está separada de la IU
Desventajas

 Acoplamiento ajustado entre View y Presentador

 Gran cantidad de interfaces para la interacción entre capas.
 El tamaño del código es bastante excesivo.

MVVM - Model View ViewModel

En general la arquitectura MVVM es diferente a MVP porque en esta arquitectura
vamos a necesitar que los datos se estén manejado de una forma más automatizada y
mucho más real time. Podemos usar varias versiones MVVM, una de ellas es data
binding que es de las más antiguas y existen en muchos otros frameworks como .NET
de Microsoft. También tenemos a Live data y RxJava o RxAndroid que no son más que
características de la programación reactiva que podemos utilizar para hacer la
actualización de datos más real time.
 Model: Igual que en arquitecturas anteriores.
 View: Sigue siendo responsable de la visualización de los datos. Se une con
variables y acciones de una forma flexible.
 ViewModel: Es el responsable de envolver el modelo y prepara los datos
observables necesitados por la vista. También proporciona enlaces a la vista para
 pasarle eventos al modelo. Los cambios en el ViewModel cambian
automáticamente la vista y viceversa.
Ventajas

 Sin acoplamiento apretado entre la vista y el modelo de vista

 No hay interfaces entre la vista y el modelo.
 Fácil de probar y el código de la unidad está basado en eventos.
Desventaja

 Debe crear observables para cada componente de la interfaz de usuario.

 El tamaño del código es bastante excesivo.

IMPLEMENTcion http://www.7sabores.com/blog/implementar-patron-mvvm-wpf