c ++ Model View Presenter: ¿Dónde construir el presentador?

8

Estoy usando el patrón de Model View Presenter (MVP) como se describe en El documento del cuadro de diálogo de Humble (pdf) con un proyecto MFC. Estoy seguro de que el problema es el mismo con la mayoría de los kits de herramientas GUI.

Lo que me molesta es la vista concreta (es decir, la clase de diálogo) está creando no solo el presentador, sino también los servicios que el presentador necesita. ¿Eso es normal? ¿Por qué la vista necesita saber qué servicios necesita el presentador? Lo que estoy pensando es que debería la dependencia inyectar al presentador en la clase de diálogo.

El control principal de la aplicación es una clase derivada de CWinApp. Entonces, ¿debo construir servicios y presentadores en esta clase y luego inyectarlos en la clase de diálogo?

Aunque, ¿cómo podría la dependencia inyectar al presentador en la clase de diálogo cuando el presentador necesita una referencia a la clase de vista en su constructor?

MyPresenter(IView *view, MyService *service);

También, ¿qué tal si la ventana principal se genera desde una ventana emergente, dónde deberían construirse los detalles para el presentador de Windows y los servicios?

Dado que esto es C ++, no creo que me interese ningún tipo de marco DI.

ACTUALIZAR

Una de las ideas que tuve fue construir el presentador con una vista nula, el constructor inyecta al presentador en la clase de diálogo, y luego en el constructor de la clase de diálogo, llame al método SetView(IView *view) en el presentador con this donde this sería la clase de diálogo (que deriva de IView). Entonces:

MyApp::Start()
{
  SomeService *service = new SomeService();
  MyPresenter *presenter = new MyPresenter(null, service);
  MyDialog *dialog = new MyDialog(presenter);
  ...
}

MyDialog::MyDialog(MyPresenter *presenter):
 presenter_(presenter)
{
  presenter_->SetView(this);
}

Parece un poco confuso pero mantiene la construcción del servicio fuera de la clase Dialog. La vista nula parece un poco peligrosa. Una alternativa sería construir una clase NullView que tuviera cuerpos de métodos vacíos y luego pasarlos al constructor del presentador.

    
pregunta User 26.10.2011 - 02:01

2 respuestas

1

¿Quizás una mejor solución es usar una clase o método de fábrica que sepa cómo crear un presentador? La vista pasaría al método de fábrica y almacenaría el valor de retorno en su miembro presentador.

Esto desacopla la información sobre cómo se construye un presentador (dependencias de los servicios o lo que sea) de la vista en sí.

    
respondido por el Jørn Jensen 21.11.2011 - 13:30
0

Creo que su idea original (construir un presentador y un servicio dentro de la vista) no hace daño. Tenemos que preguntarnos en beneficio de la inyección y no veo ninguna.

Al separar la vista real en vista abstracta y presentador, ya logró la separación de preocupaciones. Y puede beneficiarse del logro, por ejemplo, al probar al presentador con una vista rellena o burlada. Entonces, ¿por qué querría inyectar al presentador en una vista concreta? No veo ninguna necesidad.

    
respondido por el Tae-Sung Shin 08.01.2012 - 04:42

Lea otras preguntas en las etiquetas