theory - presentador - mvp android studio

¿El presentador en Model-View-Presenter crea vistas?

Question

¿Cómo se crean las vistas en MVP? ¿El Presentador siempre los crea (además de Ver en caso de subvistas)? ¿O es un componente o aplicación independiente de terceros o algo que los crea?

También agreguemos que probablemente voy a hacer esto en Dojo Toolkit / ExtJS (JavaScript).

Por lo tanto, tengo estas líneas de código:

var v = new MyApp.view.User();
var p = new MyApp.presenter.User();

¿A dónde deben ir exactamente ambas líneas? ¿El presentador crea una instancia de la vista, o viceversa? ¿Y qué instancia la primera instancia?

Answer 1

Depende ...

El objetivo principal de MVP es separar la lógica de decisión compleja del código UI de tal manera que sea más fácil de entender y mantener. A menudo, otro objetivo es hacer que la lógica de decisión en el presentador sea verificable.

El patrón MVP fue descrito por Fowler en 2004 y lo retiró en 2006 al dividir el patrón en Supervisor Conroller (SC) y Passive View (PV). En SC, la vista está vinculada al modelo pero no en PV; en PV, la vista solo la cambia el presentador directamente.

Tanto en SC como en PV, el presentador debe actualizar la vista y reaccionar a los cambios que el usuario realizó en la vista, como ingresar texto o presionar un botón. Cuando deja que los métodos de llamada Ver en el presentador, entonces surge el problema que describe porque la vista necesita una referencia al presentador y viceversa. Si hace esto, simplemente puede tomar una decisión sobre quién lo inicia todo . Las opciones son:

1. La vista crea una instancia del presentador. Cuando se carga la vista, se pasa al presentador en una función de inicialización en el presentador.
2. Al revés: Presenter crea la Vista y se pasa a la Vista en una función de inicialización en la Vista.
3. Introduces un tercer objeto que crea tanto View como Presenter, los conecta y los inicializa a ambos.

Todas las opciones le permiten alcanzar los "objetivos de MVP" de separación de preocupaciones y mayor capacidad de prueba de la lógica de decisión. No creo que ninguno de estos métodos sea teóricamente correcto o incorrecto, solo tiene que elegir el que sea más apropiado para la tecnología que utiliza. Y es mejor ser coherente en su elección a lo largo de la aplicación.

Answer 2

Estas son tus opciones:

var cvp = new ContactViewPresenter(new ContactView());

ContactViewPresenter constructor this.view = viewParam establece this.view = viewParam , y establece this.view.presenter = this . Mantiene el código en el Presentador, puede intercambiar las vistas si es necesario, y podría pasar por una prueba de simulación de la vista.

var cv = new ContactView(new ContactViewPresenter());

ContactView constructor this.presenter = cvpParam establece this.presenter = cvpParam , y this.presenter.view = this . Alguna lógica a la vista, pero no mucho. Puede intercambiar presentador si es necesario.

ContactView cv = new ContactView();
ContactViewPresenter cvp = new ContactViewPresenter();
cv.presenter = cvp;
cvp.view = cv;
cv.init();
cvp.init();

Este es un código mucho más.

ContactViewPresenter cvp = new ContactViewPresenter();

El constructor crea conjuntos this.view = new ContactView() y this.view.presenter = this .

ContactView cv = new ContactView();

El constructor establece this.presenter = new ContactViewPresenter() y this.presenter.view = this

Los dos últimos parecen un poco demasiado acoplados.

Uno es bueno porque el código permanece en el Presentador, y parece permitir las pruebas más fáciles.

Dos es agradable porque no tiene que preocuparse demasiado por los presentadores y puede preocuparse más por sus puntos de vista.

Answer 3

No creo que el Presentador deba crear una instancia de la vista, eso debería hacerlo una entidad (no en el sentido orientado a los datos, me refiero a una entidad general) fuera de la tríada de MVP. Por ejemplo, un marco de inversión de control (IoC) (si no ha oído hablar de IoC, consulte el artículo de Martin Fowler ) o algún módulo de aplicación responsable de la configuración del usuario.

Answer 4

Puede que tenga una terminología ligeramente incorrecta, pero creo que necesita identificar la raíz de la composición de su interacción; ¿Qué es lo que comienza la interacción?

En el ejemplo de formularios web que di, el formulario web es creado por la canalización Http, el evento OnInit o OnLoad es el primer punto de la tubería (según el contexto que necesite) que puede "conectar" al proceso. Por lo tanto, crea un Presenter y le da su instancia concreta de un formulario web como una interfaz de vista.

No conozco los marcos de Javascript que están discutiendo, pero supongo que hay un paso de inicialización / invocación: en ASP.NET MVC esto ocurre cuando se involucra un ActionInvoker, es el principal en una aplicación de consola.

Answer 5

Si está utilizando WebForms, entonces WebForm OnLoad o Init debería ser el lugar donde cree el Presentador; a continuación, se pasa una referencia de interfaz a la Vista que implementa el WebForm.

Entonces, algo como esto:

Presenter _presenter;
OnLoad(object sender, EventArgs e)
{
_presenter = new Presenter(this);
_presenter.Initialise();
}

Y el constructor presentador se define así:

public class Presenter
{
public Presenter(IView viewReference)
{
_viewReference = viewReference;
}
}