2008-12-09 9 views
5

Entiendo totalmente el patrón de MVP ahora, pero todavía me cuesta ver dónde se crean instancias de las vistas y los presentadores. He visto algunos ejemplos donde el presentador se actualiza en la vista, pero es correcto. Después de leer una publicación de blog de Jeremy Miller sobre la comunicación entre View y Presenter, tuvo una función en el presentador para unir al presentador a la vista.Dónde debe nacer View & Presenter

Mi pregunta es esta: ¿Dónde se deberían crear las vistas y los presentadores? También en winforms y webforms.

Respuesta

3

En formularios web, la página obtiene una instancia de la solicitud. Como la página es la vista y no puede controlar el orden de ejecución, es la vista la que tiene que registrarse con el presentador

+1

¿qué tal winforms? – adriaanp

2

En Winforms, instancia la vista según sea necesario (por ejemplo: en el método main, o en un método en otro presentador, pero donde tiene sentido realmente). La vista luego crea y se registra con una nueva instancia de un presentador.

Esto hace que tener varias vistas use la misma lógica de presentador, y protege a los usuarios de mi vista de mi decisión arquitectónica particular de usar MVP.

+0

Entonces, ¿quiere decir que su presentador conocerá la vista concreta? – Samnang

+1

No. El presentador tiene una referencia a la vista solo a través de una interfaz que implementa la vista. Esto desacopla al presentador de la implementación de la vista y hace que la lógica del presentador de pruebas unitarias sea muy fácil ya que puede usar una vista simulada para las pruebas. –

+0

Si crea una instancia de la vista como se requiere en un método en otro presentador, ¿entonces seguramente ese presentador debe conocer la vista concreta? –

1

En primer lugar una buena pregunta. En segundo lugar, puede no importar, mucho. Mi preferencia personal es conectar casi siempre Presenter y View en la Vista.

comparar este escenario:

public class SomePresenter 
{ 
    public ShowContactView(IContactView view) 
    { 
     IContact model = new Contact(); 
     new ContactPresenter(model, view); 
     view.Show(); 
    } 
} 

public class AnotherPresenter 
{ 
    public ShowContactView(IContactView view) 
    { 
     IContact model = new Contact(); 
     new ContactPresenter(model, view); 
     view.Show(); 
    } 
} 

public class YetAnotherPresenter 
{ 
    public ShowContactView(IContactView view) 
    { 
     IContact model = new Contact(); 
     new ContactPresenter(model, view); 
     view.Show(); 
    } 
} 

public partial class ContactView : Form, IContactView 
{  
    public ContactView() 
    { 
     InitializeComponent(); 
    } 
} 

a esto:

public class SomePresenter 
{ 
    public ShowContactView(IContactView view) 
    { 
     view.Show(); 
    } 
} 

public class AnotherPresenter 
{ 
    public ShowContactView(IContactView view) 
    { 
     view.Show(); 
    } 
} 

public class YetAnotherPresenter 
{ 
    public ShowContactView(IContactView view) 
    { 
     view.Show(); 
    } 
} 

public partial class ContactView : Form, IContactView 
{  
    public ContactView() 
    { 
     InitializeComponent(); 

     new ContactPresenter(new Contact(), this); 
    } 
} 

Como se puede ver que el último tiene mucha menor duplicación de código. Por supuesto, esa es una duplicación absurda o podría decir que puede mover la funcionalidad común a una función compartida, pero entiendo el punto, eso es solo un ejemplo. Es cuando tendrá la misma Vista para ser instanciada en varias partes de su aplicación.

Además, la ventaja de Ver conocer el presentador es que solo necesita hacer referencia al presentador en su proyecto de visualización, para que pueda volver a utilizar el mismo presentador en diferentes aplicaciones de interfaz de usuario. De lo contrario, tendrá que hacer referencia a cada proyecto de visualización en el presentador.

Pero lo más importante es ver cómo los diferentes modelos se adaptan a su caso. Para ser honesto, there are more possibilities even. See this duplicate question.

Cuestiones relacionadas