2012-03-18 20 views
18

Tengo una pregunta sobre cómo manejar la comunicación entre los presentadores al usar MVP. Digamos que tengo dos MVP-tríadas. Una es una lista de productos (Tríada A) y la otra es información general sobre el producto seleccionado actualmente (Tríada B).MVP ¿Comunicación entre los presentadores?

¿Cómo le digo al Presentador B que necesita actualizar porque el producto seleccionado ha cambiado por A? Por supuesto, puedo pensar en formas de hacerlo, pero me preguntaba si existe una convención general sobre cómo manejar esto.

¡Gracias de antemano por cualquier idea!

Respuesta

12

El patrón en sí realmente no prescribe cómo manejar esto.

Mi propia preferencia es un centro de mensaje/evento donde los presentadores pueden registrar interés en ciertos eventos. Evita árboles de dependencia complejos y mantiene a los presentadores a prueba.

Por ejemplo:

class PresenterA 
{ 
    void HandleProductSelectionChanged(int productId) 
    { 
     EventHub.Publish(EventType.ProductChanged, productId); 
    } 
} 

class PresenterB 
{ 
    void PresenterB 
    { 
     EventHub.Register(EventType.ProductChanged, HandleProductChanged); 
    } 

    public void HandleProductChanged(object state) 
    { 
     var productId = (int)state; 
     var productDetails = LoadProductDetails(productId); 
     view.DisplayProductDetails(productDetails); 
    } 
} 

EventHub mantendría una lista de suscriptores para invocar para cada tipo de evento.

Mantiene su capacidad de prueba: simplemente llame al HandleProductChanged para ver cómo respondería el presentador a una nueva selección de productos.

La única desventaja (como con cualquier patrón) es que introduce un nivel de indirección. Si PresenterA invocó directamente PresenterB, o PresenterB escuchó un evento en PresenterA, es obvio lo que va a suceder inmediatamente.

En este enfoque, tendría el paso adicional de ver EventType.ProductChanged, y luego encontrar qué presentadores mostraron interés en ese evento.

Según mi propia experiencia, ese único nivel de indirección vale la pena modularidad.

+1

Esto es exactamente lo que estaba buscando, se ve mucho mejor que pasar las referencias del presentador. Voy a echar un vistazo a esto mañana cuando no estoy tan cansado. Gracias. – user1277327

1

Personalmente no estoy de acuerdo la forma en que muchas personas optan por bus de eventos para solucionar este tipo de problemas

Es difícil para mí imaginar un caso en que dos presentadores necesitan comunicarse entre sí, se puede proporcionar un caso real?

En mi opinión, si dos presentadores necesitan comunicarse entre sí, debe fusionar estos dos en un solo presentador. Recuerde que también la comunicación de los objetos de los modelos entre dos casos de uso es lógica de negocios, por lo que tal vez el alcance del presentador sea mayor de lo que pensaba inicialmente.

Considere también que si usa colaboradores de la manera correcta, entonces no necesita la comunicación entre los presentadores. Los datos deben ser proporcionados por los colaboradores.

+0

Hola, ¿Puedes arrojar algo de luz sobre cómo debe uno comunicarse de modelo a presentador para que el presentador pueda realizar alguna acción a la vista. por ejemplo, por ejemplo, la lectura de la base de datos se hace en el modelo, cómo debería el modelo decirle al presentador que ha leído los datos y los ha devuelto al presentador para que el presentador pueda actualizar la vista. – eRaisedToX

+0

"la lectura de la base de datos se realiza en el modelo" ... naat XD ... prefiero crear un interactor. –